Istio在UAEK中的实践改造之路

然而，我们发现在IPv6环境下，Envoy无法劫持Pod的流量。通过抓包观察和追溯源码发现，Pod启动的时候，首先会运行一个iptables初始化脚本，完成pod内的nat redirect配置，将容器内的TCP出入流量都劫持到Envoy的监听端口中，但这个初始化脚本没有ip6tables的对应操作并且discard了所有IPv6流量，因此我们修改了初始化脚本，实现了IPv6的流量劫持。

一波刚平，一波又起。完成IPv6流量劫持后， 我们发现所有访问业务服务端口的TCP流量都被Envoy重置，进入Envoy容器中发现15001端口并没有开启。追溯Envoy和Pilot源码发现，Pilot给Envoy下发的listen地址为0:0:0:0:15001, 这是个IPv4地址，我们需要Envoy监听地址的为[::0]:15000，于是继续修改Pilot源码。

经过上述努力，应用服务端程序Pod终于能成功Accept我们发起的TCP连接。但很快，我们的请求连接就被服务端关闭，客户端刚连接上就立刻收到TCP FIN分节，请求依然失败。通过观察Envoy的运行日志，发现Envoy接收了TCP请求后，无法找到对应的4层流量过滤器(Filter)。

深入跟进源码发现，Envoy需要通过getsocketopt(2)系统调用获取被劫持的访问请求的真实目的地址， 但在IPv6环境下Envoy相关的实现存在bug，如下代码所示。由于缺少判定socket fd的类型， getsocketopt(2)传入的参数是IPv4环境下的参数，因此Envoy无法找到请求的真实目的地址，遂报错并立刻关闭了客户端连接。

发现问题后，UAEK团队立刻修改Envoy源码，完善了getsocketopt(2) 的SO_ORIGINAL_DST选项的IPv6兼容性，然后将这一修改提交到Envoy开源社区，随后被社区合并到当前的Master分支中，并在Istio1.0的Envoy镜像中得到更新使用。

到此为止，Istio SideCar终于能在UAEK IPv6环境下正常调度服务间的访问流量了。

此外，我们还发现Pilot、Mixer等模块在处理IPv6格式地址时出现数组越界、程序崩溃的情况，并逐一修复之。

性能评估

Istio1.0发布之前，性能问题一直是业界诟病的焦点。我们首先考察了增加了Envoy后，流量多了一层复制，并且请求发起前需要向Mixer Policy进行一次Check请求，这些因素是否会对业务产生不可接收的延迟。经过大量测试，我们发现在UAEK环境下会比不使用Istio时增加5ms左右的延迟，对内部大部分服务来说，这完全可以接受。

随后，我们重点考察了整个Istio Mesh的架构，分析下来结论是，Mixer Policy和Mixer Telemetry很容易成为整个集群的性能短板。由于Envoy发起每个请求前都需要对Policy服务进行Check请求，一方面增加了业务请求本身的延迟，一方面也给作为单点的Policy增大了负载压力。我们以Http1.1请求作为样本测试，发现当整个网格QPS达到2000-3000的时候，Policy就会出现严重的负载瓶颈，导致所有的Check请求耗时显著增大，由正常情况下的2-3ms增大到100-150ms，严重加剧了所有业务请求的耗时延迟，这个结果显然是不可接受的。

更严重的是，在Istio 0.8以及之前的版本，Policy是一个有状态的服务。一些功能，如全局的QPS Ratelimit配额控制，需要Policy单个进程记录整个Mesh的实时数据，这意味着Policy服务无法通过横向扩容实例来解决性能瓶颈。经过取舍权衡，我们目前关闭了Policy服务并裁剪了一些功能，比如QPS全局配额限制。

前面提到过，Mixer Telemetry主要负责向Envoy收集每次请求的调用情况。0.8版本的Mixer Telemetry也存在严重的性能问题。压测中发现，当集群QPS达到2000以上时，Telemetry实例的内存使用率会一路狂涨。

经过分析定位，发现Telemetry内存上涨的原因是数据通过各种后端Adapter消费的速率无法跟上Envoy上报的速率， 导致未被Adapter处理的数据快速积压在内存中。我们随即去除了Istio自带的并不实用的stdio日志搜集功能，这一问题随即得到极大缓解。幸运的是，随着Istio1.0的发布，Telemetry的内存数据积压问题得到解决，在相同的测试条件下，单个Telemetry实例至少能胜任3.5W QPS情况下的数据搜集上报。

问题、希望与未来

历经重重问题，一路走来，一个生产环境可用的ServiceMesh终于在UAEK环境上线了。在这一过程中，也有部门内其他团队受UAEK团队影响，开始学习Istio的理念并尝试在项目中使用Istio。然而，目前的现状离我们的初心依然存在差距。

Istio依然在高速迭代中，无论是Istio本身还是Envoy Proxy，每天都在演进更新。每一次版本更新，带来的都是更为强大的功能，更为简练的API定义，同时也带来了更复杂的部署架构。从0.7.1到0.8，全新的路由规则v1alpha3与之前的API完全不兼容，新的virtualservice与原先的routerule截然不同，给每位使用者构成了不少麻烦。

如何完全避免升级Istio给现网带来负影响，官方依然没有给出完美平滑的升级方案。此外，从0.8到1.0虽然各个组件的性能表现有显著提升，但从业内反馈来看，并没令所有人满意，Mixer的Check缓存机制究竟能多大程度缓解Policy的性能压力依然需要观察。

值得一提的是，我们发现的不少bug同时也在被社区其他开发者发现并逐一解决。令我们开心的是，UAEK团队不是信息孤岛，我们能感受到Istio官方社区正在努力高速迭代，始终在致力于解决广大开发者关心的种种问题，我们提交的issue能在数小时内被响应，这些，都让我们坚信，Istio是一个有潜力的项目，会向Kubernetes一样走向成功。

从UAEK接入用户的经验来看，用户需要正确地使用好Istio离不开前期深入的Istio文档学习。UAEK后续需致力于要简化这一过程，让用户能傻瓜化、界面化、随心所欲地定制自己的路由规则成为我们下一个愿景。

UAEK团队始终致力于改革UCloud内部研发流程，让研发提升效率，让运维不再苦恼，让所有人开心工作。除了继续完善ServiceMesh功能，下半年UAEK还会开放更多的地域和可用区，提供功能更丰富的控制台，发布自动化的代码管理打包持续集成(CI/CD)特性等等，敬请期待!

作者介绍

陈绥，UCloud资深研发工程师，先后负责监控系统、Serverless产品、PaaS平台ServiceMesh等开发，有丰富的分布式系统开发经验。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!