本文分享自华为云社区《华为云云原生团队：Istio数据面新模式 Ambient Mesh技术解析》，作者： 云容器大未来。

如果说在以 Kubernetes 为基础构建起的云原生世界里，哪种设计模式最为经典，Sidecar 模式无疑是其中最有力的竞争者。当需要为应用提供与自身逻辑无关的辅助功能时，在应用 Pod 内注入对应功能的 Sidecar 显然是最 Kubernetes Native 的方式，而 Istio 则是这种模式的代表。

Istio 项目的愿景是以尽量透明的方式，解决微服务场景下，服务间的连接、安全以及可观测性问题。主要实现手段则是通过在应用旁部署一个 Proxy，在 Kubernetes 场景下则为应用 Pod 注入 Sidecar，拦截应用流量至 Sidecar。Sidecar 根据从 Istio 控制面获取的用户配置对应用流量进行处理，以一种对应用代码几乎无侵入的方式实现了服务治理。

图 1

虽然 Istio 并不局限于仅支持 Kubernetes 平台，但是 Istio 的设计理念与 Kubernetes 的 Sidecar 模式有着天然的亲和性。基于 Sidecar 模式，Istio 能够实现在 Kubernetes 平台上的快速开发、部署、验证。同时，在功能层面，Isito 将服务治理功能从应用代码中剥离，作为基础设施下沉至 Sidecar，抽象出了事实上的云原生应用网络层，极大地减轻了应用开发者的心智负担，这部分能力刚好也是 Kubernetes 生态一直以来缺失的。基于 Istio 对于 Kubernetes 生态的完美补充，随着 Kubernetes 的大规模普及，Istio 也实现了对用户心智以及市场的快速抢占。

虽然以 Sidecar 模式部署 Istio 数据面似乎是一个理所应当，让人无法拒绝的选择，但是需要强调的是，Istio 完整功能的实现并不与 Sidecar 模式强绑定，我们还有各种各样其他的选择。另外，随着对于 Istio 使用程度不断加深，落地规模不断扩大，可以发现以 Sidecar 模式部署 Istio 数据面诸多挑战：

1. 侵入性：Istio 基本实现了对应用代码的零侵入，但是由于 Sidecar 的注入需要更改 Pod Spec 并且对应用流量进行重定向，因此应用接入网格时需要重启 Pod，而应用容器与 Sidecar 容器的启动顺序不确定造成的冲突也可能导致应用中断；

2. 生命周期绑定： Sidecar 本质上是基础设施，它和应用的生命周期往往不一致，因此升级 Sidecar 时也需要对应用 Pod 进行重启，同样可能导致应用中断，而对于 Job 类应用，Sidecar 的存在则会导致 Pod 无法被及时清理；

3. 资源利用率低：Sidecar 为单个应用 Pod 独占，应用的流量存在波峰波谷，而一般情况下 Sidecar 的内存占用与集群规模（Service 数目，Pod 数目）强相关，因此需要按照极端情况预留资源，导致集群整体的资源利用率低。同时由于需要为每个 Pod 注入 Sidecar，随着集群规模的不断扩大，Sidecar 占用的资源总量也会线性上涨。

针对 Sidecar 部署模式的缺陷，Google 和 Solo.io 联合推出了一种新的 Sidecar-less 部署模式 --- Ambient Mesh。

架构介绍

图 2

Ambient Mesh 架构如上图所示，从设计的角度来看，它主要有以下两个特点：

1. Sidecar-less：为了避免上述 Sidecar 模式的种种缺陷，Ambient Mesh 不再为任何 Pod 注入 Sidecar，将网格功能的实现进一步下沉到 Istio 自有组件中。

2. L4/L7 处理分层：Ambient Mesh 引入了 ztunnel 和 waypoint 两个组件用于代替原来的 Sidecar 实现相关功能，与 Sidecar 既能处理 L4，又能处理 L7 流量的实现方式不同，Ambient Mesh 对两者进行了区分，ztunnel 只负责 L4 流量的处理，L7 的流量则按需交由 waypoint 处理。

Ambient Mesh 的控制面与原先 Sidecar 模式的 Istio 相比基本没有变化，数据面的组件构成以及各个组件的作用如下：

1. istio-cni：必装组件，以 DaemonSet 的形式部署。其实 istio-cni 并不是 Ambient Mesh 的新增组件，在原先的 Sidecar 模式中就已经存在，当时主要用于替代 istio-init 这个 Init Container 配置流量拦截规则，同时规避 istio-init 引发的安全问题。Ambient Mesh 对它进行了扩展，以必装组件的形式部署，负责配置流量转发规则，劫持本节点中已加入 Ambient Mesh 的 Pods 的应用流量，转发至本节点的 ztunnel；

2. ztunnel: 必装组件，以 DaemonSet 的形式部署。ztunnel 对所在节点 Pods 的流量进行代理，主要负责 L4 流量的处理、L4 的遥测以及服务间 mTLS（双向认证）的管理。最初 ztunnel 基于 Envoy 实现，但是考虑到对 ztunnel 功能的有意约束以及对安全性、资源占用率的要求，社区已经用 rust 从零构建该组件；

3. waypoint：按需配置，以 Deployment 的形式部署。waypoint 负责处理 HTTP，故障注入等 L7 功能。以负载或者 Namespace 粒度进行部署，在 Kubernetes 中，即一个 Service Account 或者一个 Namespace 对应生成一个 waypoint 的 Deployment，用于处理发往对应负载的七层流量，同时 waypoint 实例数可以根据流量动态伸缩。

图 3

下面以 Ambient Mesh 数据面实际的处理过程来展示上述各个组件在其中扮演的具体角色：

1. 与 Sidecar 模式类似，Ambient Mesh 也能以网格、Namespace 以及 Pod 的粒度将服务加入网格；不同的是，新加入的 Pod 无需重启，更不需要注入 Sidecar；

2. istio-cni 监听本节点内 Pods 的增删以及进出网格的情况，动态调整转发规则，网格内 Pods 发出的流量会被透明地转发至本节点的 ztunnel，直接跳过 kube-proxy 的处理；

3. ztunnel 同样需要对本节点 Pods 的增删以及进出网格的情况进行监听，从控制面获取位于本节点且被网格接管的 Pods 的证书并进行管理；

4. 源端 ztunnel 对拦截的流量进行处理，根据流量的源 IP 找到对应 Pod 的证书，由此和对端建立 mTLS；

5. 如果要访问的目标服务没有配置 waypoint 或者没有配置 L7 相关的处理策略，则源端 ztunnel 直接和目的端 ztunnel 建立连接（如上图黄线标注），对端的 ztunnel 终止 mTLS，执行 L4 安全策略，将流量转发到目标 Pod；

6. 如果目标服务配置了 waypoint（利用特殊配置的 Gateway 对象）以及 L7 的处理策略，则源端 ztunnel 会和对应的 waypoint 建立 mTLS，waypoint 终止 mTLS 后，进行 L7 的逻辑处理，之后再与目标 Pod 所在节点的 ztunnel 建立 mTLS，最终同样由目的端的 ztunnel 终止 mTLS 并将流量发往目标 Pod。

价值分析

虽然从底层实现来看，Ambient Mesh 和原有的 Sidecar 模式的差别巨大，但是从用户面看，两者在核心 Istio API（VirtualService, DestinationRules 等）的使用方式、实现效果都是一致的，能够确保基本相同的用户体验。Ambient Mesh 是 Istio 社区除 Sidecar 模式外，支持的第二种数据面模式，所以网格技术本身能为用户带来的价值，Ambient Mesh 与先前的 Sidecar 模式并不二致。因此这里只对 Ambient Mesh 相对于原生 Sidecar 模式的价值进行分析，对于网格本身的价值不再赘述。

Ambient Mesh 主要是针对 Istio 的数据面架构进行调整，用于克服既有 Sidecar 模式的不足，因此它的价值产生必然是基于其架构特点。前文已经提到过 Ambient Mesh 的架构特点主要有“Sidecar-less”和“L4/L7 处理分层”这两点，下面就从这两点出发进行价值分析：

1. Sidecar-less 的优势，其实可以看作 Sidecar 模式缺陷的对立面：

a) 透明：网格功能下沉至基础设施，不仅对应用代码零侵入，和应用的生命周期也完全解耦，做到真正对应用透明，允许应用与网格独立演进；

b) 优化资源占用：数据面占用的 CPU、内存等资源不再随着实例数线性增长，随着数据面的实例数减少，与控制面的连接数也相应减少，极大地减轻控制面的资源与处理压力。

2. 对于为什么要对 L4/L7 进行分层处理，首先要区分两者之间的区别。与 L4 相比，L7 的处理更为复杂，需要占用更多的 CPU/内存等资源，不同类型的操作之间资源占用也存在较大差别；同时操作越复杂暴露的攻击面越大。另外 Envoy 当前并不支持对不同租户的流量进行强隔离，“Noisy Neighbor”的问题不可避免。因此 Ambient Mesh 分层处理架构的优势如下：

a) 资源利用率高：ztunnel 仅负责 L4 的处理，L4 处理较为简单且资源占用较为固定，所以更易对 ztunnel 进行资源规划，无需过量预留资源，能够将更多的节点资源供用户使用；waypoint 更可以根据 L7 负载动态扩缩容，充分利用集群中的资源碎片；

b) 租户隔离：处理复杂、安全风险高的 L7 处理由租户（Service Account）各自的 waypoint 处理，既避免了租户间的资源抢占，又限制了安全问题的爆炸半径；

c) 平滑落地：允许用户逐步接入网格，当仅需网格的 L4 处理能力时，完全无需考虑 L7 的资源占用以及可能造成的潜在负面影响（例如：因为错误配置导致进入 L7 处理而应用并未完全遵守 L7 协议，导致服务中断），之后在适当时刻按需开启相关功能即可。

当然 Ambient Mesh 作为 Istio 全新的数据面架构，在社区中依然以实验特性的形式存在，仍然有许多问题亟待解决，例如：

1. 性能：尤其是针对 L7 的处理，Ambient Mesh 需要经过两个 ztunnel 以及一个 waypoint，肉眼可见地又额外增加了一跳，因此完整的 L7 处理需要额外经过三跳。虽然社区声称这对性能的影响很小，但是仍需待其特性稳定后进一步观察对比；

2. 容器网络适配：虽然 Ambient Mesh 与应用基本实现了完全解耦，但是反过来也增加了网格与底层基础设施的耦合，Sidecar 模式仅需在 Pod 的 net ns 实现流量的拦截处理，但是 Ambient Mesh 在主机网络进行流量拦截，显然需要更多考虑与底层容器网络的适配；

3. 配置复杂：原本 Envoy 复杂的配置就被广为诟病而 Ambient Mesh 更需要实现一个 ztunnel 对节点所有 Pods 的代理，配置复杂度更是上升一个数量级，同时配置的复杂意味着处理流程的增加，也会对数据面的排错以及整体性能造成影响；

4. 其他：ztunnel 的高可用？waypoint 事实上将原本双端的 L7 处理变为了单端，对 L7 监控指标正确性的影响？…

未来展望

从版本发布的角度，自从 2022 年 9 月份发布以来，Ambient Mesh 一直作为实验特性存在于独立的分支之中。因此对于 Ambient Mesh 下一步的计划就是合入主干分支（已于 2023 年 2 月实现）并作为 Alpha 特性发布，最终在 2023 年底到达 Stable，实现生产可用。

从 API 的角度，最理想的是能在两种架构下共用同一套 API。当然这是不现实的，因为已有的一部分 Istio API 是以 Sidecar 模式部署为前提条件设计的。最典型的就是 Sidecar 这个 CRD，它用于定制化下发至不同 Sidecar 的配置，从而减少 Sidecar 不必要的资源占用。这些 Sidecar-Only 的 API 显然在 Ambient Mesh 下毫无意义。同时，Ambient Mesh 自身也引入了 ztunnel 和 waypoint 两个独有组件，因此 Ambient Mesh 也需要创建新的 API，用于管理这些独有组件以及实现一些 Ambient Mesh Only 的功能。最终 Ambient Mesh 会实现已有的核心 Istio API（VirtualService, DestinationRules 等）并创建一些其独有的 API，重要的是做到三类 API（Sidecar 模式独有、Ambient Mesh 独有、两者共有）统一的使用与交互。

那么 Ambient Mesh 是否做到了对 Sidecar 模式使用场景的全覆盖，从而让 Sidecar 模式彻底退出历史舞台了呢？答案自然是否定的，类似于业界各种独占模式和共享模式之争，Sidecar 模式本质上是应用 Pod 对 Proxy 的独占。专属的 Proxy 往往能保证更好的资源可用性，尽量避免其他应用的影响，确保高优先级应用的正常运行。可以预见，最终两种模式的混合部署，应用按需选择代理模式是更为理想的方式。所以构建混合部署模式，保证该模式下两种模式的良好兼容性和统一的体验也将是后续工作的重点。

总结

Sidecar 模式对于 Istio 就像一场原型验证，以一种最 Kubernetes Native 的方式快速展示网格技术的价值，抢占用户认知和市场。不过随着 Istio 的落地逐渐进入深水区，开始在生产环境大规模部署，Sidecar 模式就显得力不从心了。此时 Ambient Mesh 以一种更符合大规模落地要求的形态出现，克服了大多数 Sidecar 模式的固有缺陷，让用户无需再感知网格相关组件，真正将网格下沉为基础设施。

但是显然 Ambient Mesh 并不是网格数据面架构演进的终点。当前还没有一种网格数据面方案能在侵入性、性能、资源占用等各个考量维度做到完美。Ambient Mesh 基本做到了对应用的零侵入，但是 L7 的三跳处理引发的性能问题，ztunnel 等常驻进程的资源占用令人无法忽视；gRPC 等 RPC 库通过内置实现 xDS，直连 Istio 控制面，将网格杂糅进 SDK，确实能实现很好的性能和资源占用表现，只是不可避免地需要付出与应用强耦合、多语言支持复杂度高等固有代价；基于 eBPF 直接将全套网格数据面功能像 TCP/IP 协议栈一样下沉到内核貌似是理想的终局方案，只是考虑到内核安全以及与内核交互的复杂性，eBPF 的执行环境其实是非常受限的，例如 eBPF 程序加载到内核前必须经过 verifier 的校验，执行路径必须完全已知，无法执行任意的循环。因此对于 HTTP/2，gRPC 等复杂的 L7 处理，基于 eBPF 的开发和维护都会比较困难。

考虑到基础设施对性能、资源损耗的极致要求以及过往相关技术的演进规律，例如对于基础网络，绝大多数应用共享使用内核协议栈即可，部分特殊应用利用 DPDK，RDMA 等专用技术进行加速。同样，对于网格数据面，多种技术结合，分别优化相应场景的解决方案，可能是更具可行性的。可以预见，这类方案基本上是以类 Ambient Mesh 的节点级代理作为主体，随着网格以及 eBPF 技术的发展，将尽量多的网格数据面功能下沉至 eBPF（Fast Path）实现；少部分高级功能交由用户态的 Proxy（Slow Path）实现；那些对性能、隔离性等有较高要求的应用，则为其部署专属的 Sidecar。这样一来，就能满足绝大多数场景下，对侵入性、性能、资源占用等各个维度的要求。

综上 ，最终是一套数据面方案一统天下，还是各种方案混合部署，取各家所长，仍有待对相关技术不断探索演进，再用实践检验，最后让时间告诉我们答案。

参考文献

[1] Istio Ambient Mesh Explained: https://lp.solo.io/istio-ambient-mesh-explained

[2] What to expect for ambient mesh in 2023: https://www.solo.io/blog/ambient-mesh-2023

[3] Introducing Ambient Mesh: https://istio.io/latest/blog/2022/introducing-ambient-mesh

[4] Get Started with Istio Ambient Mesh: https://istio.io/latest/blog/2022/get-started-ambient

点击关注，第一时间了解华为云新鲜技术~