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

众所周知，由于 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 在双栈技术方面的实现方案解决这个问题。

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

图二：Kubernetes 双栈技术发展时间线

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

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

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

根据目前从社区以及各个厂家的实践情况来看，双栈技术方案主要有如下三个：开启 IPv4 协议栈兼容的方案（IPv4-Compat 方案）基于生成重复协议栈的方案（Istio Dual Stack Proposal）基于方案二的优化 -- 消除重复配置并提升可扩展性（Istio Dual Stack Optimization Proposal）下面我们基于上述的三个方案分别展开评估。

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

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

  
  

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

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

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

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

图三：Istio 实验分支双栈支持示意图

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

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

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

  
  

缺点：

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

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

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

图四：Istio 主干分支双栈支持示意图

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

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

  
  

缺点：

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

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

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

图五：Istio 双栈技术发展时间线

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

表一：Istio 双栈软件组件基本要求

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

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

物理机硬件配置如下：

表二：Istio 双栈实现硬件配置表

软件组件相关信息如下：

表三：Istio 双栈实现软件组件配置表

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 为 version，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 和 Jaeger 系统功能，均符合预期。

图十：Kiali 服务拓扑图

图十一：Jaeger 链路追踪图

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 。

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

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

5 月 26-27 日，QCon 全球软件开发大会即将落地广州，从下一代软件架构、研发效能提升、现代编程语言、AIGC、数据驱动业务、金融级分布式数据库、工业互联网、出海的思考、Web3.0 时代的金融系统、大前端架构等角度与你探讨，欢迎你来现场打卡交流～

点击底部【阅读原文】直达大会官网，现在购票享 8 折优惠，组团购票还有更多折扣，感兴趣的同学请联系票务经理：15600537884（电话同微信）。