国内首例社区双栈Istio方案落地经验，实现代码已开源

作者 张怀龙、张海文 编辑 邓艳琴

本文整理自中国移动云能力中心高级软件工程师、Istio社区Member张海文和Intel云原生开发工程师、Istio的维护者和Linkerd的开发者张怀龙老师在QCon全球软件开发大会（北京站）的演讲《移动云服务网格双栈技术的实践之路》。下载完整幻灯片地址如下：https://qcon.infoq.cn/202302/beijing/presentation/4898

背景介绍

众所周知，由于IPv4地址的消耗殆尽，且在未来5G和物联网等行业趋势的推动下，IPv6地址的普遍运用是大势所趋。然而网络中主要服务提供商在网络及其应用全部升级到IPv6协议之前，通信兼容是必须要解决的问题，而双协议栈技术在其中必将扮演着举足轻重的角色。

所谓双栈是双协议栈（Dual Stack）技术的简称，即是指在一台设备上同时启用IPv4和IPv6两套协议栈。因此该设备既能和IPv4网络端点通信，又能和IPv6网络端点通信。网络端点一般是指通信端节点，包括主机和路由器等设备。尽管有其他技术（比如网络隧道和NAT-TP技术等）可以使得IPv6结点保持与纯IPv4节点的通信兼容，但双栈技术始终是最直接的方式。

移动云双栈需求

随着使用IPv6成为大势所趋，2020年工信部发布了《工业和信息化部关于开展2020年IPv6端到端贯通能力提升专项行动的通知》（工信部通信函〔2020〕57号）【1】，其中提到一项重点工作任务为大幅提升包括移动云在内的多个云服务平台IPv6业务承载能力，2021年工信部和网信办又发布了《两部门关于印发《IPv6流量提升三年专项行动计划（2021-2023年）》的通知》（工信部联通信〔2021〕84号）【2】，为了全面落实国家部门关于IPv6提升的专项行动计划，移动云将通过双栈方式实现公有云产品IPv4/6访问作为2022年重点工作。

移动云绝大部分公有云产品都实现了云原生化，Istio作为云原生服务网格领域主流技术，在移动云上获得了广泛的使用，目前将近50款产品通过Istio及生态组件进行灰度发布、流量治理及服务可观测，为移动云产品快速迭代、线上稳定提供了有力支撑。

但由于Istio在双栈技术上的缺失，移动云产品面临双栈访问需求和Istio使用需求的矛盾，急需Istio在双栈技术方面的实现方案解决这个问题。

云原生领域IPv4/6双栈介绍

随着云计算及云原生相关标准和技术的普遍运用落地，Kubernetes容器编排系统和服务网格（Service Mesh）等基础技术得到行业的深度应用。其中，Kubernetes的双栈支持作为测试特性早在Kubernetes v1.16（alpha）就已经存在，并在进行了全面测试以后，双栈特性作为功能完备的特性被集成在Kubernetes v1.21之中，自从Kubernetes v1.22开始，Kubernetes双栈技术的支持已经被作为稳定的特性而存在，并于Kubernetes v1.23版本中进入正式发布（GA）阶段【3】。同时越来越多的云服务提供商也为双栈Kubernetes集群提供了支持。

尽管如此，在业界广泛应用的服务网格项目（以大家所熟知且应用最为广泛的Istio和Linkerd为例）中，双栈技术的支持依然是缺失的。

为了更好的实现服务网格与Kubernetes在双栈支持上的协同工作，满足移动云等用户在Istio双栈方面的需求，本文主要介绍了服务网格的代表项目Istio在双栈技术中的实现方案以及该方案在移动云的落地实现场景。

Istio双栈解决方案

本文对Istio的双栈支持的实现方案主要参考社区提议（Proposal）【4】。根据其设计思路并基于Istio v1.14-dev的版本进行代码改造。同时，目前的实现代码已经放到社区的Istio repository中一个名为experimental-dual-stack的分支【5】。

双栈方案实现

根据目前从社区以及各个厂家的实践情况来看，双栈技术方案主要有如下三个：

1. 开启IPv4协议栈兼容的方案（IPv4-Compat方案）

2. 基于生成重复协议栈的方案（Istio Dual Stack Proposal）

3. 基于方案二的优化——消除重复配置并提升可扩展性（Istio Dual Stack Optimization Proposal）

下面我们基于上述的三个方案分别展开评估。

方案一：开启IPv4协议栈兼容的方案（IPv4-Compat方案）

优点：

• 修改代码最少，且无需修改过多核心代码

• 可以实现网格内部service最基本的双栈需求

缺点：

• 依赖数据面的flag（ipv4_compat）控制协议兼容

• 对于单集群服务网格中引入非网格内的服务时，会导致服务不可用的情况（网格内服务访问普通K8s service失败）

• 对多集群服务网格之间的服务访问也存在上面两点问题

方案二：基于生成重复协议栈的方案（Istio Dual Stack Proposal）

如果用户的Istio启用了双栈特性（通过引入环境变量ISTIO_DUAL_STACK来启用），那么Istio控制面会为用户的边车代理同时创建基于IPv4和IPv6协议栈所需的各类xDS配置资源，这些由Istio控制面下发的核心配置资源包括LDS，RDS，CDS和EDS。如图三所示。

优点：

• 能够完整的实现双栈支持，并且与Kubernetes的双栈无缝结合

• 对于单集群的外部服务引入以及多集群之间的服务访问都能很好支持

• 没有相关依赖，在Istio CNI和Calico IPVS开启时都能正常工作

缺点：

• 需要改动大量Istio核心代码

• 对于任意双栈service会生成几乎重复的服务网格配置，造成数据面的资源损耗

方案三：基于方案二的优化——消除重复配置并提升可扩展性（Istio Dual Stack Optimization Proposal）

本方案需要服务网格的控制面和数据面一起进行修改，目前依然在继续努力中，但是在社区已经取得相应的进展，并将于即将发布的Istio 1.17中实现基本的双栈特性支持。具体的实现思路如图4所示。

优点：

• 拥有方案二中的所有优点

• 消除了方案二中存在的重复配置，降低了资源损耗

缺点：

• 需要同时改动控制面和数据面的代码

最终选型落地方案

根据上述三个方案的对比分析，方案一首先被排除，其次由于方案三的实现时间不可控，于是果断选取了方案二的实现方式，同时等待方案三合并到主干分支以后再循序渐进的切换。

图五展示了Istio双栈支持在社区中的支持时间线：

除此以外，方案中对Istio双栈实现的软件组件有如下基本要求：

落地场景

基于对IPV4/IPV6双栈的市场/客户需求，英特尔携手移动云梳理了Istio在移动云上的落地场景，抽象出对应的模型Demo进行测试验证（目前Istio经典Demo bookinfo部分微服务不支持双栈，不能使用bookinfo进行验证），共同排查遇到问题并将解决代码贡献给社区，最终双栈方案通过了所有测试。

测试环境为3台物理机构成的一套Kubernetes集群。

物理机硬件配置如下：

软件组件相关信息如下：

灰度发布

Istio在移动云中应用最广泛的场景是灰度发布，灰度发布细分场景较多，按照产品在Kubernetes集群中的部署方式，可以分为单租户和多租户场景下的灰度发布，按照灰度发布范围，可以分为入口微服务灰度发布、内部微服务灰度发布、全链路微服务灰度发布。

我们进行了单租户和多租户场景下的灰度发布测试，在单租户场景中又按灰度发布范围进行了细分场景测试，以下是我们的测试验证介绍。

单租户

单租户场景即Istio部署模型中的Single Cluster模型【6】在移动云中的应用，指一款产品独占一套Kubernetes集群，并部署在一个namespace中，通过一套Istio管理该Kubernetes集群，这是最简单部署场景。

入口微服务灰度发布

入口微服务灰度发布指对产品入口处微服务进行灰度发布的场景，该场景需要Istio Ingress Gateway结合入口微服务进行灰度发布。我们的验证模型架构图如下：

数据面流量通过Istio Ingress Gateway，转到微服务foo，正常请求访问v0.0.1版本foo服务，通过HTTP请求Header中设置key-value对，key为version，value为v0-0-2，流量流转到v0.0.2版本的foo服务。

内部微服务灰度发布

内部微服务灰度发布指对产品内部的微服务进行灰度发布的场景，我们的验证模型架构图如下：

上游访问client服务，client服务再请求provider服务，provider提供两个版本的服务：v0.0.1和v0.0.2，正常情况下访问v0.0.1的服务，当Header中设置key-value对，key为ver sion，value为v0-0-2时，流量流转到v0.0.2版本的provider服务。

全链路微服务灰度发布

全链路微服务灰度发布指在产品微服务链路中，对多个微服务进行灰度发布及验证的场景。我们的验证模型架构图如下：

用户通过Istio Ingress Gateway访问client服务，client服务再请求provider服务。client提供两个版本的服务：v0.0.1和v0.0.2，正常情况下访问v0.0.1的服务，当用户通过Gateway访问client服务时，Header中设置key-value对，key为clientVersion，value为v0-0-2时，流量流转到v0.0.2版本的client服务。provider也提供两个版本的服务：v0.0.1和v0.0.2，正常情况下访问v0.0.1的服务，当用户通过Gateway访问client服务时，Header中设置key value对，key为providerVersion，value为v0-0-2时，流量流转到v0.0.2版本的provider服务。

多租户

多租户场景即Istio部署模型中的Namespace Tenancy模型【7】在移动云中的应用，指多款产品共享一套Kubernetes集群，每款产品部署在单独的namespace中，通过探索的多租户场景部署方案【8】，实现多款产品共享控制面，独占数据面的场景。

我们在多租户场景下进行了入口微服务灰度发布细分场景的测试验证，验证模型架构图如下：

foo和bar两款产品共享一套Kubernetes集群，foo和bar namespace下分别部署foo、foo独占的Istio Ingress Gateway及bar、bar独占的Istio Ingress Gateway。

产品foo的访问流量通过foo namespace的Istio Ingress Gateway，转到微服务foo，正常请求访问v0.0.1版本foo服务，通过HTTP请求Header中设置key-value对，key为version，value为v0-0-2，流量流转到v0.0.2版本的foo服务。产品bar同理。

流量治理

我们选择移动云产品广泛使用的限流功能进行了流量治理相关的验证测试。我们对入口微服务灰度发布场景中foo服务应用限流规则，通过fortio向Istio Ingress Gateway + foo应用发起IPv4和IPv6协议的并发请求，请求结果符合限流预期。

可观测性

我们按照Istio官方的运维组件集成文档【9】，在双栈环境中集成部署了Prometheus、Kiali、Jaeger等可观测性组件。通过双栈方式请求Istio纳管的验证Demo，查看Kiali和Jae ger系统功能，均符合预期。

总结与展望

移动云双栈落地总结与展望

Istio双栈方案通过验证后，我们第一时间将方案落地，把双栈版Istio集成到移动云云原生平台产品中并进行了充分测试，使其成为了国内首款为客户提供在双栈环境下通过Istio进行灰度发布、流量治理、服务拓扑、链路追踪等能力的产品【10】；同时我们和多款移动云产品进行试点对接并完成上线，未来会有更多移动云产品通过Istio实现双栈访问、灰度发布、流量治理及服务观测。

社区双栈特性总结与展望

事实上，社区是非常欢迎Istio双栈特性能够被支持的，并且有许多企业级的用户正在想办法完成他们自己的双栈实现，正因为如此才有Istio双栈特性在独立的分支上持续演进。

基于当前的实现虽然能够满足双栈的支持，但是其最大的问题在于Istio的控制面分别为IPv4和IPv6家族地址生成了重复的边车代理配置信息，这会带来更多的资源损耗。因此，最终的方案是消除这些重复的配置信息，并将双栈特性的最终实现推进到Istio的主干分支中。

目前为了实现这个目标，Intel和Aspen Mesh等企业正积极的在Istio和Envoy社区合作，并推进这项工作。而且目前也取得了很多实质性的进展。相信在不远的未来，Istio的双栈特性的支持将会变得越来越好，而Istio也将会成为更多用户首选的服务网格产品。

另外值得一提的是，当前的实现方案由于是实验性的分支，因此并没有完善单元测试和集成测试，但是一些企业级用户已经基于当前的代码实现完成了数百个测试用例的校验，因此对于基本通用的用户场景的校验已经是完成了的。同时需要补充一点，根据当前的实现版本，Istio CNI和Calico IPVS等特性都已经做过验证。我们欢迎并鼓励更多有双栈需求的用户在非生产环境上去体验Istio的双栈支持，同时如果有任何问题需要交流，也请踊跃加入我们Istio社区的slack channel:#dual-stack-support。

参考连接

[1]: http://www.gov.cn/zhengce/zhengceku/2020-03/23/content_5494661.htm

[2]: https://www.miit.gov.cn/zwgk/zcwj/wjfb/txy/art/2021/art_3c42d01d124b426e98b4400830da8fd8.html

[3]: https://kubernetes.io/zh-cn/blog/2021/12/08/dual-stack-networking-ga/

[4]: https://docs.google.com/document/d/1oT6pmRhOw7AtsldU0-HbfA0zA26j9LYiBD_eepeErsQ/

[5]: https://github.com/istio/istio/tree/experimental-dual-stack

[6]: https://istio.io/latest/docs/ops/deployment/deployment-models/#single-cluster

[7]: https://istio.io/latest/docs/ops/deployment/deployment-models/#namespace-tenancy

[8]: https://cloudnative.to/blog/istio-multi-tenancy-exploration/

[9]: https://istio.io/latest/docs/ops/integrations/

[10]: https://ecloud.10086.cn/home/support/cloudnative

作者简介

张怀龙，Intel云原生开发工程师，拥有丰富的云计算开发经验，曾参与百度运维部运维PaaS平台的研发工作，通过开源和企业级项目开发IBM公有云PaaS监控解决方案Marmot，之后通过运用开源及企业级应用，比如Prometheus、Sysdig、NewRelic、InfluxDB、Grafana等技术实现IBM公有云新一代PaaS平台监控系统的迁移方案。现就职于英特尔开源技术中心，参与云原生项目服务网格相关的研发工作。并担任Istio的维护者和Linkerd的开发者。Github ID: zhlsunshine

张海文，中国移动云能力中心高级软件工程师、Istio社区Member。拥有丰富的互联网及云原生开发经验，先后在京东，百度等互联网公司从事搜索广告系统开发，现就职于中国移动云能力中心，专注于云原生和服务网格相关产品的研发，目前为公司服务网格负责人，先后实现近50款移动云产品服务网格落地实践。