在生产中使用Istio,我们学到了什么?

首先,给大家简单介绍一下Istio,Istio是一个Service Mesh的开源框架,来自Google,大部分使用Go语言来开发,是Service Mesh的集大成者。

Istio数据层面主要使用envoy,Istio开发了一些 filter 扩展envoy的功能,这些功能主要集中在mixer上。Istio是新鲜出炉的技术,2017年5月0.1 release版本横空出世,不过版本更新迭代很快,最新的版本是今年3月发布的,1.1.3版。

 

Istio简介

Istio在逻辑架构上由数据平面和控制平面组成。数据平面是经典的实现方式,由一组以 sidecar 方式部署的智能代理(Envoy)组成。这些代理可以调节和控制微服务及 Mixer 之间所有的网络通信。

在每一个容器中注入了一个sidecar,Istio的sidecar称之为Istio proxy,相当于envoy 加上Istio开发的envoy filter。Istio proxy可以拦截整个容器的入口和出口流量。根据sidecar从数据层面接受到的规则和策略,进行一系列对于网络流量的配置和管理,比如路由管理,加密,遥测数据收集。控制平面负责管理和配置代理来路由流量,此外,控制平面还配置 Mixer 以实施策略和收集遥测数据。

 

Istio有几大块功能,首先是流量控制,这个基本上是通过Istio里的pilot组件来实现的。从图上我们可以看到,rules api就是pilot提供的抽象API,用户通过api来配置相应的规则。Paltform Adapter主要是兼容不同的平台。用户针对不同的平台实现服务发现等功能。基于用户的规则和从平台收集的数据,通过envoy api把具体的规则下发到各个容器的Istio proxy。 这里实现了大部分我们需要的流量管理功能,例如负载均衡策略,路由控制。我们可以把本来发给服务A的请求,都导向另一个服务。 故障注入,为测试进行模拟。以及熔断,url重写,重试,超时等等。

 

Istio的第二块,主要是安全机制。我们可以对网格内的微服务通讯进行tls加密。在发起请求的Istio proxy对请求使用tls证书加密,在接受请求的Istio proxy对这个请求解密,这对于应用的开发者是无感的。Istio最优秀的地方就是对于业务开发者的基本无感。这些网络调用相关的功能和策略被抽离出来,不用再放在应用的代码里。

Istio还提供了类似k8s rbac的权限实现方式。在servicerole定义使用service api的权限,通过service role binding绑定在k8s service account上,然后当应用通过service accout启动后, 该应用就有service role里定义的访问其他服务的权限。

 

下面一块是策略和遥测,这个是Istio中争议非常大的一个功能。好的方面是设计非常干净。Istio proxy只需要把它收集到的attribute发给mixer,mixer的Adapter基于attribute来做相应的操作。一类attribute用来做策略检查,例如Qouta,另一类用来做遥测数据收集,如promothues。 这其中体验不好之处就在策略检查上面。因为每个请求都需要做这个检查,这个检查目前看来会影响整体的性能。1.1开始,Istio提供了简单的方式可以关闭全局这个检查。如果你对性能要求比较高,目前最好还是先关闭。

Istio 1.1的发布对性能进行了大幅优化。官方提供的数据是:1000 k8s service, 2000个sidecar,每秒70000个请求在这个mesh网格中。这时候每个proxy使用0.6个CPU,50M内存来支持每秒1000个请求。Istio的遥测,就是mixer需要0.6个cpu来支持每秒1000次的请求。这个地方并没有说是不是包括策略检查。我感觉是不包含的。pilot需要1个cpu和1.5G的内存来做服务下发。最后,Istio proxy对服务间调用的性能影响是tp90 8ms。

微服务体系带来的问题

原来的微服务体系中都面临哪些难题呢?

首当其冲是定位和调试困难。当遇到bug或者性能问题,原来的方式基本都是逐级排查,从客户遇到问题的地方开始。因为一个深层次的微服务会引起一系列的上层微服务出现问题。如果发现两个服务直接之间的整体调用性能不好,这个时候哪怕你找到某一次性能差的日志或数据,基于这个数据和日志找出来的原因不一定是root cause。这种排查问题的方式就像烽火台,你只看到了最近的烽火台,并不知道起点在哪。

 

第二,测试时数据会有遗漏,缺少完整的测试数据。

最好的测试数据是线上的真实数据。但是线上的请求采集下来还需要独立开发相应的程序,整体实现很麻烦。另外,如果测试微服务的错误处理,对于QA的黑盒测试来说,这还需要一个可配置的错误生成器。这点对于测试也是一个独立的工作。

 

第三,缺少上线流程。

我们原来使用独立的微服务作为开关,来判断是否加载新功能。在新的功能代码外层加上调用该微服务的代码,根据返回值来判断是否执行新功能代码,上线完成后再把开关代码删掉,的确有点麻烦。上线前需要修改源码增加控制,上线完成后还需要在源码中删除这些逻辑。没有简单、无侵入的金丝雀和灰度发布的实现方式。

 

第四,微服务间的网络调用策略配置不灵活。

不同的客户环境需要使用不同的网络策略,例如重试,超时等等设置,如果对应的设置没有通过配置文件暴露出来,就只能对代码进行修改。而且这些代码在业务代码里,统一的维护和升级都需要独立的流程。

灵雀云ASM如何解决上述问题?

灵雀云从去年就开始有针对性地在ASM产品中解决这些问题。下面是我们ASM的总体架构图:

ASM controller是我们开发的K8s controller,主要处理我们自己定义的crd,以及做一些自动化的K8s资源处理;Dablo是ASM的前端界面;controller和diablo都会直接和K8s api server来通讯;Istio gateway是Istio用来服务南北流量的接口,主要用来暴露集群里的微服务;jaeger分为collector和query;collector直接从Istio proxy收集上报的调用链路数据,目前数据格式还是用的zipkin,jqeger query是用来显示调用链路的;为了做namespace的数据隔离,我们对jaeger的组件都做了相应的改造;存储方式是ES;遥测数据用prometheus来存储,数据从mixer收集而来;diablo通过直接调用prometheus api来获取。

 

关于定位和调试,灵雀云主要通过两方面来解决:一方面使用promothues里的遥测数据来绘制实时的拓扑图。展示调用关系,以及调用数据,包括流量,性能,错误率等。另一方面,通过jaeger的调用链来解决。我们可以查看完整的调用链路,具体到某次调用的时候,请求的内容,以及返回的状态码。

 

下面是我们预览版产品中的一些截图。这个截图来自于灵雀云PaaS平台的数据。我们可以看到整个平台所有组件之间的调用关系,右边是某两个组件之间的调用数据,包含调用次数,rps,以及响应时间这样的性能指标。这些可以帮助我们快速做定性的判断。

后面两张图是我们嵌入的jaeger query组件。当前面做了定性判断后,这里可以查询具体的问题是什么,通过过滤条件来缩小范围,然后具体看某一个请求的详细信息。

 

为了使用Istio这些功能,需要做些什么配置呢?

1.所有的微服务中注入sidecar;
2.pod里的container声明了自己监听的端口,保证能够拦截入口流量;
3.pod的label需要app和version两个key;
4. K8s service里声明的port都必须包含name字段,根据使用的协议name的格式有一定的规则。例如使用是http协议,name可以为http或者以“http-”开头;
5.服务调用的代码需要做稍微的改造,需要获取上一个请求header里的一些字段,包括request id,trace_id, span_id。把他们设置在header中传递给下一个调用。这个在Istio官方的文档里可以找到。

除了最后需要对代码做少许的修改,前面都只是需要修改服务部署的yaml。

 

通过Istio提供的流量镜像功能,我们可以很容易的使用生产环境来测试新的代码。只需要把测试代码通过一个独立的应用直接发布到生产环境,然后通过配置把流量拷贝一份调用这个测试代码的应用就好了。

Istio的错误注入功能很容易模拟返回错误的状态码,增加请求返回的延迟。

 

在安全上线方面,在生产环境同时发布新、老版本,通过拓扑图和调用链的数据,来观测新版本是否可以正常工作。我们通过流量的权重来实现灰度发布,通过一些规则设置来实现金丝雀发布。加上前面的生产环境测试,对于安全上线提供了很大的保证。

 

最后,灵活的网络策略。通过istio的Virtual Service和Destination Rule这两种资源,实现灵活的配置微服务间的网络访问策略。终于不用把这些策略的配置写到我们的代码里来,Istio的virtual service和destiinatio rule就完全实现了。

K8S中文社区微信公众号

评论 抢沙发

登录后评论

立即登录