Beyond Istio OSS——Istio服务网格的现状与未来

作者：宋净超（Jimmy Song），原文地址：https://jimmysong.io/blog/beyond-istio-oss/

本文根据笔者在 GIAC 深圳 2022 年大会上的的演讲《Beyond Istio OSS —— Istio 的现状及未来》^[1] 整理而成，演讲幻灯片见 腾讯文档 ^[2] 。

本文回顾了 Istio 开源近五年来的发展，并展望了 Istio 服务网格的未来方向。本文的主要观点如下：

• • 因为 Kubernetes、微服务、DevOps 及云原生架构的流行，导致服务网格技术的兴起；

• • Kubernetes 和可编程代理，为 Istio 的出现打下了坚实的基础；

• • 虽然 eBPF 可以加速 Istio 中的透明流量劫持，但无法取代服务网格中的 sidecar；

• • Istio 的未来在于构建基于混合云的零信任网络；

Istio 诞生的前夜

2013 年起，随着移动互联网的爆发，企业对应用迭代的效率要求更高，应用程序架构开始从单体转向微服务，DevOps 也开始变得流行。同年随着 Docker 的开源，解决了应用封装和隔离的问题，使得应用在编排系统中调度变得更容易。2014 年 Kubernetes、Spring Boot 开源，Spring 框架开发微服务应用开始流行，在接下来的几年间大批的 RPC 中间件开源项目出现，如 Google 在 2016 年发布 gRPC 1.0，蚂蚁在 2018 年开源 SOFAStack^[3] 等，微服务框架百花齐放。为了节约成本，增加开发效率，使应用更具弹性，越来越多的企业正在迁移上云，但这不仅仅是将应用搬到云上那么简单，为了更高效地利用云计算，一套「云原生」方法和理念也呼之欲出。

Istio 开源时间线

Istio 开源发展时间线如下图所示。

Istio 开源发展时间线示意图

下面我们来简单回顾下 Istio 开源大事件：

• • 2016 年 9 月：因为 Envoy 是 Istio 中的重要组成，Istio 的开源时间线应该有 Envoy 一部分。起初 Envoy 在 Lyft 内部仅作为边缘代理，开源前已在 Lyft 内部得到大规模生产验证并受到了 Google 工程师的注意 1^[4]，那时候 Google 正打算推出一个服务网格的开源项目。2017 年，Lyft 将 Envoy 捐献给了 CNCF^[5] 。

• • 2017 年 5 月：Istio 由 Google、IBM 和 Lyft 联合宣布开源 2^[6]。一开始就使用了微服务架构，确定了数据平面和控制平面的组成以及 Sidecar 模式。

• • 2018 年 3 月：Kubernetes 顺利的成为从 CNCF 中第一个毕业的项目，变得越来越「无聊」，基础 API 已经定型，CNCF 正式将服务网格（Service Mesh）写入到了云原生的第二版定义 3^[7] 中。笔者当前就职的公司 Tetrate^[8] ，也是在那时由 Google Istio 初创团队创业成立的。服务网格在中国开始爆发，ServiceMesher 社区也在蚂蚁集团的支持下成立，在中国布道服务网格技术。

• • 2018 年 7 月：Istio 1.0 发布，号称「生产可用」，Istio 团队重组。

• • 2020 年 3 月：Istio 1.5 发布，架构回归单体，发布周期确定，每三个月发布一个大版本，API 趋于稳定。

• • 2020 年至今：Istio 的发展主要着重于 Day 2 Operation 4^[9]、性能优化和扩展性发面，多个围绕 Istio 生态的开源项目开始出现，例如 Slime^[10] 、Areaki^[11] 、Merbridge^[12] 。

为什么 Istio 会在 Kubernetes 之后出现？

微服务和容器化之后，异构语言使用的增加，服务的数量激增，容器的生命周期变短是导致服务网格出现的根本原因。

我们先来看下服务从部署在 Kubernetes 到 Istio 中架构的变迁，然后再探讨架构演进过程中 Istio 的需求，下文假定读者已了解 Kubernetes^[13] 和 Istio 的架构 ^[14] 。

Kubernetes 到 Istio 的架构改变示意图

从 Kubernetes 到 Istio，概括的讲应用的部署架构有如下特点：

• • Kubernetes 管理应用的生命周期，具体来说，就是应用的部署和管理（扩缩容、自动恢复、发布策略）；

• • 基于 Kubernetes 的自动 sidecar 注入，实现了透明流量拦截。先通过 sidecar 代理拦截到微服务间流量，再通过控制平面配置管理微服务的行为。如今服务网格的部署模式也迎来了新的挑战，sidecar 已经不是 Istio 服务网格所必须的，基于 gRPC 的无代理的服务网格 5^[15] 也在测试中。

• • 服务网格将流量管理从 Kubernetes 中解耦，服务网格内部的流量无须 kube-proxy 组件的支持， 通过类似于微服务应用层的抽象，管理服务间的流量，实现安全性和可观察性功能。

• • 控制平面通过 xDS 协议发放代理配置给数据平面，已实现 xDS 的代理有 Envoy^[16] 和蚂蚁开源的 MOSN^[17] 。

• • Kubernetes 集群外部的客户端访问集群内部服务时，原先是通过 Kubernetes Ingress^[18] ，在有了 Istio 之后，会通过 Gateway 来访问 6^[19]。

Kubernetes 容器编排与可编程代理 Envoy 为 Istio 的出现打下了坚实的基础。

从上面 Kubernetes 到 Istio 的架构的转变的描述中，我们可以看到为了让开发者最小成本地管理服务间的流量，Istio 需要解决三个问题：

1. 1. 透明劫持应用间的流量：Istio 开源最初的目标是成为网络基础设施，就像水和电人类的基础设施一样，我们使用水电不需要关心如何取水和发电，只需要打开水龙头，按下开关即可。透明流量劫持对于开发者来说，就像使用水和电，不需要修改应用程序就可以快速使用 Istio 带来的流量管理能力；

2. 2. 代理集群的运维：如何为每个应用注入一个代理，同时高效地管理这些分布式的 sidecar 代理；

3. 3. 可编程代理：代理可以通过 API 动态配置，还要有出色的性能与可扩展性；

以上三个条件对于 Istio 服务网格来说缺一不可，而且，从中我们可以看到，这些要求基本都是对于 sidecar 代理的要求，这个代理的选择将直接影响该项目的走向与成败。为了解决以上三个问题，Istio 选择了 Kubernetes 容器编排和可编程代理 Envoy。

透明流量劫持

如果你使用的是如 gRPC 这类中间件开发微服务，在程序中集成 SDK 后，SDK 中的拦截器会自动为你拦截流量，如下图所示。

gRPC 的拦截器示意图

如何让 Kubernetes pod 中的流量都通过代理呢？答案是在每个应用程序 pod 中注入一个代理，与应用共享网络空间，再通过修改 pod 内的流量路径，让所有进出 pod 的流量都经过 sidecar，其架构如下图所示。

Istio 中的透明流量劫持示意图

从图中我们可以看到其中有一套非常复杂的 iptables 流量劫持逻辑（详见 Istio 中的 Sidecar 注入、透明流量劫持及流量路由过程详解 ^[20] ），使用 iptables 的好处是适用于任何 Linux 操作系统。但是这也带来了一些副作用：

1. 1. Istio 网格中所有的服务都需要在进出 pod 时都增加了一个网络跳跃点（hop），虽然每次 hop 可能只有两三毫秒，但是随着网格中服务和服务间的依赖增加，这种延迟可能会显著增加，对于那种追求低延迟的服务可能就不适用于服务网格了；

2. 2. 因为 Istio 向数据平面中注入了大量的 sidecar，尤其是当服务数量增大时，控制平面需要下发更多的 Envoy 代理配置到数据平面，这样会使数据平面占用大量的系统内存和网络资源；

针对这两个问题，如何优化服务网格呢？

1. 1. 使用 proxyless 模式：取消 sidecar 代理，重新回到 SDK；

2. 2. 优化数据平面：减少下发到数据平面的配置的频率和大小；

3. 3. eBPF：使用 eBPF 优化网络劫持；

本文将在后面性能优化 ^[21] 一节讲解这些细节。

Sidecar 运维管理

Istio 是在 Kubernetes 的基础上构建的，它可以利用 Kubernetes 的容器编排和生命周期管理，在 Kubernetes 创建 pod 时，通过准入控制器自动向 pod 中注入 sidecar。

为了解决 Sidecar 的资源消耗问题，有人为服务网格提出了有四种部署模式，如下图所示。

服务网格的四种部署模式示意图

下表中详细对比了这四种部署方式，它们各有优劣，具体选择哪种根据实际情况而定。

模式	内存开销	安全性	故障域	运维
Sidecar 代理	因为为每个 pod 都注入一个代理，所以开销最大。	由于 sidecar 必须与工作负载一起部署，工作负载有可能绕过 sidecar。	Pod 级别隔离，如果有代理出现故障，只影响到 Pod 中的工作负载。	可以单独升级某个工作负载的 sidecar 而不影响其他工作负载。
节点共享代理	每个节点上只有一个代理，为该节点上的所有工作负载所共享，开销小。	对加密内容和私钥的管理存在安全隐患。	节点级别隔离，如果共享代理升级时出现版本冲突、配置冲突或扩展不兼容等问题，则可能会影响该节点上的所有工作负载。	不需要考虑注入 Sidecar 的问题。
Service Account / 节点共享代理	服务账户 / 身份下的所有工作负载都使用共享代理，开销小。	工作负载和代理之间的连接的认证及安全性无法保障。	节点和服务账号之间级别隔离，故障同 “节点共享代理”。	同 “节点共享代理”。
带有微代理的共享远程代理	因为为每个 pod 都注入一个微代理，开销比较大。	微代理专门处理 mTLS，不负责 L7 路由，可以保障安全性。	当需要应用 7 层策略时，工作负载实例的流量会被重定向到 L7 代理上，若不需要，则可以直接绕过。该 L7 代理可以采用共享节点代理、每个服务账户代理，或者远程代理的方式运行。	同 “Sidecar 代理”。

服务网格的四种部署模式对比

可编程代理

Flomesh 的张晓辉曾在 为什么需要可编程代理 ^[22] 博客中详细说明了代理软件的发展演化过程，我下面将引用他的一些观点，说明可编程代理 Envoy 在 Istio 中的关键作用。

下图展示了代理从配置到可编程模式的演化过程，及每个阶段中的代表性代理软件。

代理软件的演化示意图

整个代理演化过程都是随着应用从本地和单体，越来越走向大规模和分布式。下面我将简要概括代理软件的发展过程：

• • 配置文件时代：几乎所有软件都有配置文件，代理软件因为其相对复杂的功能，更离不开配置文件。该阶段的代理主要使用 C 语言开发，包括其扩展模块，突出的代理本身的能力。这也是我们使用代理最原始最基础的形式，这些代理包括 Nginx、Apache HTTP Server、Squid^[23] 等；

• • 配置语言时代：这个时代的代理，更具扩展性和灵活性，比如动态数据获取和配套的逻辑判断。代表性代理包括扩 Varnish^[24] 和 HAProxy；

• • 脚本语言时代：从脚本语言的引入开始，代理软件才真正走向的可编程，我们可以更方便的使用脚本在代理中增加动态逻辑，增加了开发效率。代表性的代理是 Nginx 及其支持的脚本语言；

• • 集群时代：随着云计算的普及，大规模部署和动态配置 API 成了代理所必需的能力，而且随着网络流量的增加，大规模代理集群也应运而生。这个时代的代表性代理有 Envoy、Kong 等；

• • 云原生时代：多租户、弹性、异构混合云、多集群、安全和可观测，这些都是云原生时代对代理所提出的更高要求，代表性软件有 Istio、Linkerd、Pypi^[25] ，它们都为代理构建了控制平面。

这些都是服务网格吗？

现在我将列举一些流行的服务网格开源项目，让我们一起探索服务网格的发展规律和本质。下表对比了当前流行的服务网格开源项目 7^[26]。

对比项	Istio	Linkerd	Consul Connect	Traefik Mesh	Kuma	Open Service Mesh (OSM)
当前版本	1.14	2.11	1.12	1.4	1.5	1.0
许可证	Apache License 2.0	Apache License 2.0	Mozilla Li