如何理解Istio在FreeWheel微服务中的实践-创新互联
如何理解Istio在FreeWheel微服务中的实践,针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
成都创新互联公司基于成都重庆香港及美国等地区分布式IDC机房数据中心构建的电信大带宽,联通大带宽,移动大带宽,多线BGP大带宽租用,是为众多客户提供专业达州主机托管报价,主机托管价格性价比高,为金融证券行业服务器托管,ai人工智能服务器托管提供bgp线路100M独享,G口带宽及机柜租用的专业成都idc公司。FreeWheel的微服务之痛
FreeWheel是一家数字视频解决方案公司,我们核心业务系统可以理解为一个Web ERP。最初核心业务系统完全基于Rails,是一个典型的三层架构,但这个大型单体应用在发展了近十年以后,维护成本越来越大,而且难以扩展。2016年FreeWheel开始迁移到微服务架构,所有的业务功能都用Golang来重写,同时引入了Kubernetes作为服务的部署平台。
但在迁移到微服务之后,FreeWheel面临很多通信方面的矛盾。一方面,平台层的运维开始和应用层的改动互相牵制。有时升级核心网络设备,整个系统都会被波及。另一方面,随着应用层越来越快的迭代,模块之间开始互相牵制,进而影响了客户,同时也降低了应用迭代的效率。归结起来是两方面的问题:一个是通信的控制,另外一个是通信的可见性,可以理解成监控。
最初我们尝试用一个中心化的服务网关Gateway来解决这种矛盾。但随着迁移微服务的模块越来越多,这种服务出现了两个矛盾:一个是服务和服务之间的流量互相影响,第二个是在微服务中服务网关的配置有很多个性化的地方,大锅饭带来了复杂的配置管理,渐渐难以为继。
在这样的背景下,FreeWheel切换到了Service Mesh解决方案,选择了Istio。
FreeWheel选择Istio解决方案的主要原因,是因为FreeWheel的技术栈是Golang和Kubernetes,Istio是目前最合适的选择。
02
Istio的架构和基本原理
首先来看一下Istio的架构和基本原理。Istio有四个核心模块:
1. 反向代理模块: Istio Proxy劫持Pod的所有流量,管理Service Mesh里面的通信。同时,管理Mesh内外边界交互的流量也是反向代理。
2. Pilot模块: 管理所有Service Mesh的动态配置。
3. Citadel模块: 主要是自动维护服务之间通信的证书。
4. Mixer模块: 在Kubernetes部署了两组服务:一组服务提供授权和容量检查的能力,另外一组Policy提供数据采集的能力,通过该服务将数据汇总。
如果从整个系统设计上看,也可以分成四个板块:
1. 反向代理。
2. 网络安全,目前主要兼容Spiffe标准实现。
3. 为C++实现的Proxy接入K8s的动态配置管理。
4. 对于Attribute的有限状态机模型,授权、容量、管理监控等所有的基础。
03
Istio管理下的微服务
Service Mesh部署pod之后,发生了什么?
1. 创建Pod之前,首先由Sidecar Injector来将自定义的initContainer, sidecar container、volume添加到Pod中,这里的volume是Istio自带的通信安全相关的,Istio为Pod维护了动态的认证密钥。
2. 接下来创建容器启动Pod,其中initContainer先为当前Pod生成流量劫持的iptables规则。
3. 然后启动Pod中的sidecar和实际应用容器。
4. 接下来sidecar和Pilot建立连接接受动态配置和更新;和Mixer(policy)建立连接来检查授权、容量等;和Mixer(telemetry)建立连接来上报流量相关的监控元数据。
Pod启动完成并且接入Service Mesh后,这里面还有两个组件:
Galley:实现对动态配置的校验。
Citadel:检查Pod中mount的secret的有效性,并自动为Pod分发合法的证书。
04
FreeWheel如何充分利用Istio?
FreeWheel已经有一套复杂的自定义认证、授权机制,为了充分利用Istio,我们通过扩展Istio来整合这些系统,涉及两方面:
扩展Sidecar:加入认证支持,提供了对业务系统的认证支持,将用户相关信息以header的形式传入Mesh,后续的授权、监控、限流都可以用Istio原生的机制来完成。
扩展Mixer:选择一部分流量来应用对应的授权逻辑。
扩展Sidecar接入认证
FreeWheel原本就有一个简单的服务网关实现,将认证逻辑抽取到这个模块中,认证完成之后在反向代理中为下游的服务插入一些header,比如认证后得到的用户信息等。
Istio没有开发这种对请求完全定制的接口,所以要想修改请求和响应的内容,就必须要定义反向代理。我们没有替换Envoy,改为在它下面接一个反向代理来实现,这个反向代理同时还接入了配置管理服务,可以利用原生的k8s配置管理接口来实现动态配置管理。不过需要注意的是,Sidecar里面的容器的流量默认是不被Iptables劫持的,如果需要纳入流量劫持,需要显式指定Aannotation来包含端口或者CIDR。
接入Sidecar其实就是修改Istio-system/istio-sidecar-injector的ConfigMap,并加入自定义的反向代理。
这个反向代理很简单,写死了token和用户信息的映射关系,如果上游传入了token,就将用户信息塞到header中传给下游,然后流量被转发给应用服务,在反向代理和应用服务之间还有一个检查授权、容量的过程,这是通过定制Mixer来实现的。
通过在Sidecar中增加FreeWheel自定义认证支持,下游可以充分利用Istio提供的授权、限流、监控接口。不过在Sidecar Injector用了一段时间以后,发现里面有两个问题:
Sidecar没有K8s自动注入的secret,也无法通过容器内环境变量自动建立Master连接,需要管理额外的Kubernetes。
Sidecar内的服务流量默认是不被劫持的,如果需要劫持需要添加额外的Annotation。
扩展Mixer接入授权
我们为实现高度定制的请求和响应内容时,用Sidecar实现扩展,但服务在授权、自定义限流的时候,很多类似的功能并不需要修改请求响应,只是在请求到达下游服务之前算一下,结果拒绝,或者通过。这时候就可以通过Mixer来扩展。
Mixer是一个高度可定制的状态机模型,Envoy提供两个接口:Report 和Check。这两个接口会在连接和请求的不同生命后期被多次调用,我们经常用到的Quota,Metrics,Tracing 之类的功能都是通过它来实现的。
下图为Mixer的基本原理,Template是对Proxy上报的Attribute的特定处理机制的框架,支持四类:
Preprocess: 汇总流量相关元数据和环境(k8s)相关的元数据。
Report: 上报数据。
Check: 决策是否允许当前访问。
Quota: 决策容量是否足够。
Mixer的基本原理
FreeWheel是如何扩展Mixer的呢?
首先,增加了一个adapter来实现授权的模板。其实,FreeWheel已有一个默认的RBAC模板。但新增一个授权能力的时候,我们希望做到绝对可控。比如,通过一个动态配置,在只有某一部分user或访问某一类URL的时候打开这个授权,其他的时候则把它关掉。
Mixer提供了一种非常灵活的模型,让Handler可以在流量中动态地选择一部分来引入额外的机制(如权限控制、限流等),在应用运维中这是很重要的能力,只要是不修改请求、响应的功能都可以采用扩展Mixer来实现。
这里,mymock会完全拒绝所有被匹配到的流量:
mymock Handler的基本原理
在扩展Mixer的过程中有三个关键要素:
1. Handler的配置。这是一个默认行为,让checknothing匹配到user1的时候返回到400,然后全部拒绝。
2. 系统进程instance。这是每个模块固定的东西,定义了这种输入以后,里面可以有一个黑盒,是面向对象的概念。
3. RUL。当用户身份是user1的时候,instance会被handler来处理。如果要扩展,第一步需要定义handler的数据结构;第二步,实现time的接口,这里有两个接口;第三把定义的handler的文件里面相关go的接口通过代码生成。最后,注册到mixer里面,重新编译打包mixer以后就可以直接用了。
需要注意的是,mixer接入的是授权的policy模块,可能会影响服务网格(Service Mesh)不工作。因此,重新部署这些模块的时候,如果不能忍受短时间的宕机,则可能需要做一些灰度发布的机制。
对于Istio配置管理,我们也发现一些性能瓶颈和局限性。
Kubernetes和对etcd配置管理存在性能瓶颈。单个Resource控制在K级别,能够比较正常的工作,一旦到达万级别可能会出现不工作,比如好几万的单个Resource。
Istio配置本身的局限性。首先是防抖动处理,集群里面部署变化再快,都不会阻塞Istio。其次Istio其他的配置没有防抖动处理,一旦用程序插入的时候一定要做限流。最后Istio用了CRD无法做到的兼容性设计,所以升级CRD也没有办法做到平滑的升级。
FreeWheel未来将怎么做?
首先是Service Contract,封装Istio以及平台层其他配置的复杂度,抽象出一个安全,高效的应用运维体系,为未来技术上的改进留出空间。
然后是Chaos Testing,解决复杂的微服务系统的持续运营和风险控制问题。这个也是目前比较火的一个主题。
现场问答
1. 对于Service Mesh外部流量进入,在Kubernetes有Ingress,在微服务Service Mesh的应用里面也有一个Gateway的情况下,它里面是把Gateway转到Service Mesh,这三个怎么联动让外部的流量能够顺畅地进去?
答:很简单。Service Mesh可以理解成是一个封闭的盒子,你所有的外部的Ingress以前该怎么运作还怎么运作,我们现在就讨论在Service Mesh里面是怎么运作的。如果把它看作一个黑盒,现在你有一个Ingress,可以把它转到Istio里面的Ingress Gateway,过去流量会直接转发到各个Pod,是直接打到Pod,由Pod上Sidecar,再转给应用。
2. 您刚才说的Sidecar里的应该是直接把Pod里面的流量屏蔽掉,只能通过Service Mesh里面的Gateway流量才能够进到Pod里面?
答:不会。你说的这个流量转发其实并没有任何的限制,Service Mesh里面每一个反向代理都可以承担Ingress Gateway的功能,仅仅是路由配置的问题。如果把这个弄好了,在任何一个Service Mesh上都可以配置这个功能。这个反向代理是一模一样的。
3. 我用Istio的Gateway,Kubernetes里面的Ingress关掉,能够跟外部之间联系。
答:这个才是Istio比较推荐的模式,你管理这个集群外部进来流量的时候直接走Ingress Gateway,可以做到很好的限制。
4. 你们在落地的过程中有没有遇到一些坑?
答:有。我们一开始试图把业务的权限数据直接转成原生的数据结构,因为我们想用它来做权限控制。但是后来发现它掌控不了那么大的数据量。第二个坑是Istio对它的一些Resource是没有防抖动处理的,可能会导致这个Service Mesh行为很不稳定,在客户端一定要做限流。
另外从长远看,Istio的这些模块目前都还是单点,可能导致Service Mesh不可用。我们以前也有遇到过跑了三个月莫名其妙出问题了,维护这种监控系统要频繁地做演习。我们公司现在一个月做一次演习,会定时在一个主生产环境里把问题拿出来,然后检查各个环节有没有正常工作,这也是我们未来会发展的一个事情。
关于如何理解Istio在FreeWheel微服务中的实践问题的解答就分享到这里了,希望以上内容可以对大家有一定的帮助,如果你还有很多疑惑没有解开,可以关注创新互联行业资讯频道了解更多相关知识。
另外有需要云服务器可以了解下创新互联cdcxhl.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
网站题目:如何理解Istio在FreeWheel微服务中的实践-创新互联
转载来源:http://myzitong.com/article/gedie.html