大家好，我是 Jimmy Song，现任 Tetrate 的 Developer Advocate，欢迎来到我的演讲——“超越 Sidecar：深入解析 Istio Ambient Mode 的流量机制与成本效益”。 我们今天会聚焦 Istio 今年非常火的新特性——Ambient Mode，这种新模式号称能去掉 Sidecar，带来更低的资源开销与更简单的运维。 在接下来的时间里，我会带大家一步步了解 Istio Ambient Mode 的架构、流量路径，以及它在生产实践中可能带来的价值与限制。希望能帮助大家快速评估并上手这项技术。

这是我今天的分享大纲，主要分为五个部分： 1）先和大家聊聊为什么需要一个新的数据面模式。 2）然后介绍 Ambient Mode 的核心概念和组件。 3）我们会深入看看它的流量拦截和转发机制，也就是它最核心的部分。 4）会跟现有的 Sidecar 模式做一个对比，看看两者在功能、性能和运维上的差异。 5）最后做一个总结，然后留点时间给大家 Q&A。 我们先看第一部分，“为什么要关注 Ambient Mode”？

首先，我们来思考一个问题：为什么要关注、甚至尝试这种新模式？Sidecar 在服务网格里一直都用得好好的，为什么要“去 Sidecar”呢？ 让我们看看当前服务网格面临的一些问题和挑战。

这里列出了服务网格在生产上常见的一些问题： 以前在每个 Pod 里都注入一个 Sidecar Envoy，让我们可以做流量观测、mTLS 加密等高级功能。但随着微服务规模越来越大，Sidecar 带来的 CPU、内存消耗 也变得很显著。 在升级 Istio 或者 Envoy 时，需要对所有 Pod 做滚动更新；这不仅花费大量运维精力，还会对业务可用性造成影响。 业务对 高性能、低成本 的追求越来越强烈，Sidecar 模式下的资源浪费和管理麻烦已经成为一大痛点。 我们就要思考：能不能在 保持核心的安全、可观测、流量控制能力 的同时，减少 Sidecar 带来的这些额外负担？

其实服务网格的发展也一直在探索各种代理部署位置，比如： Sidecar：在每个 Pod 内跑一个 Envoy； Ambient：将代理从 Pod 中剥离到节点级； Cilium Mesh：利用 eBPF 在内核空间做 L4，然后再结合 Envoy 做 L7； gRPC：直接将网格能力集成到 SDK 里。 不同的模式在功能、安全、性能、管理复杂度上也不尽相同。Ambient 是 Istio 官方推出的新尝试，我们接下来会详细探讨它。

Ambient Mode 是 Istio 项目为了应对 Sidecar 的资源和管理成本而提出的新架构。 不再在每个 Pod 里放 Envoy，而是改用节点级的 ztunnel 提供 L4 流量转发与加密。 需要 HTTP / gRPC 等 L7 能力时，部署一个 “Waypoint Proxy” 作为可选的代理，不再强制所有 Pod 都注入代理。 这样做在大规模集群中可以节省很多资源和运维精力，而仍然保留了 mTLS 和基本流量管理能力。

这是一个简单的对比表，我们可以看到： Sidecar 模式：安全性高，但资源消耗大，运维相对繁琐。 Ambient 模式：依靠 ztunnel 提供加密，Waypoint 提供 L7，整体更高效，管理也更简单，但目前还在不断完善。 Cilium mesh：利用 eBPF 在内核态处理流量，效率高但配置也复杂； gRPC：如果你是 gRPC 重度用户，可以将它集成到客户端中。 每种模式都有自己的优劣，这就看项目需求了。

这里是另一张对照图，我们用“效率”和“安全性”两个维度把几种模式分布在象限里。可以看到 Sidecar 与 Ambient 各有侧重。 Ambient 更偏向资源效率与可管理性，Sidecar 则是对隔离与安全要求特别严格时更合适。 当然，Cilium Mesh、gRPC 也是各有应用场景。

接下来我们正式进入第二部分，深入看看 Ambient Mode 的具体组件，包括 ztunnel、Waypoint Proxy 以及 Istio CNI 在其中扮演的角色。

在 Ambient 模式中，有三个核心角色： ztunnel：每个节点部署一个轻量级 L4 代理，用来拦截和加密流量。 Waypoint Proxy：可选的 L7 代理，当我们需要鉴权、路由、可观测等 HTTP 层功能时才会部署，按命名空间、服务或 Pod 级别灵活配置。 Istio CNI：现在用 CNI 来完成流量劫持，不再需要在每个 Pod 注入一个 init 容器。 这样一来，就把大部分负担从每个 Pod 中移除，提高了资源效率，也更容易运维。

这张图展示了 Ambient 模式的整体架构，我们可以看到两个覆盖层，一个是 ztunnel 安全层，一个是 Waypoint 代理层。 每个节点上跑一个 ztunnel，对所有在这个节点上的 Pod 进行流量拦截与加密。 如果某些服务需要 L7 能力，则在对应的命名空间或者服务上部署一个 Waypoint Proxy，流量只在需要时才经过它。 Control Plane 依然是 Istiod，负责给 ztunnel 和 Waypoint 下发证书和配置。 这样就减少了在每个 Pod 中都要运行 Envoy Sidecar 的需求。

Waypoint Proxy 的部署是非常灵活的： 如果你有一个命名空间下大多数服务都需要 HTTP 层策略，可以部署一个共享的 Waypoint。 如果只有特定关键服务需要 L7 代理，可以给它们单独布一个 Waypoint。 也可以针对某个 Pod 定制，或者在多个 Namespace 间做共享。 这就比 Sidecar 模式更弹性，也不会强制所有服务都进行 L7 代理。

接下来再看 Istio CNI： 过去我们在 Sidecar 模式里常常用一个 init 容器来注入 iptables 规则；Ambient 改为用 CNI 来做这件事情。 无论是 Sidecar 还是 Ambient，都可以用这个 CNI；而且它支持 非特权模式，让我们的 Kubernetes 集群更加安全。 在 Ambient 下，CNI 会在 Pod 内部配置 iptables，把对外流量转到 ztunnel 的端口。

这张图简单示意了 Istio CNI 如何与 Kubernetes 本身的网络插件（如 Calico、Cilium 等）组合在一起。它修改了本机的 CNI 配置，增加了 CNI 链，在 Kubernetes 分配完 Pod IP 后，紧接着就会执行 Istio CNI 的拦截逻辑，把网络流量规则注入到 Pod netns。并且为不同模式中 Pod 配置不同的 iptables 规则。 这样就与原本的 CNI 配置（包括网络策略）形成一个链式流程，不会相互冲突。

这张图详细描绘了当 Pod 启动时，Istio CNI 会怎么做： 它会进入 Pod 的网络命名空间，创建一套 iptables 规则，把流量劫持到 ztunnel 监听的 socket 上。 不再需要在每个 Pod 里注入 init 容器，也不需要特权权限，这就让整体部署更干净、也更安全。 ztunnel会在pod的网络命名空间中建立一个socket，并且为节点上的每个pod都会建立一个。

介绍完组件之后，我们来看看最核心的“流量路径”。zTunnel 和 Waypoint 究竟是怎么拦截并转发流量的？我们会从透明流量拦截、HBONE 协议等角度进行解析。

如图所示，Kubelet 在节点上启动了一个 Pod，这个事件被 Istio CNI Agent 监听到，Istio CNI Agent 进入 Pod 的网络空间，设置 iptables 规则将流量重定向到本地 socket，并将 Pod 的文件描述符（FD）发送为 ztunnel。ztunnel 获取到 FD 之后就可以在 Pod 的网络空间中创建 socket。 Pod 在发送流量时，本该直连目标地址，但是 iptables 规则会把它拦截到本节点的 ztunnel 进程里，然后 ztunnel 决定这条流量需不需要交给 Waypoint 做 L7 代理。 如果不需要，就直接在 L4 层把它加密转发到目标 Pod；如果要 L7，例如鉴权，就再把流量隧道给 Waypoint。

这是一个简化的 6 个步骤的生命周期： 1）数据从 Pod 发出，被 CNI 重定向到 ztunnel； 2）ztunnel 做加密，如果需要 L7 再： 3）把流量交给 Waypoint； 4）Waypoint 做高级策略； 5）再回到目标节点或本节点的 ztunnel； 6）最终到 Pod。 对于大多数只需 L4 代理的场景，这样就非常高效。

HBONE 是 Ambient 中非常重要的协议，它利用 HTTP/2 CONNECT 来建立隧道，结合 mTLS 做加密。 这样做有几个好处： 多路复用，减少了额外的连接； 通过 CONNECT 隧道传输任意 L4 流量； 让 ztunnel、Waypoint 能更灵活地处理分层策略。 这也跟 Sidecar 模式里 Envoy-to-Envoy 的通信方式不太一样。 ztunnel之间、ztunnel和Waypoint代理之间都可以建立 HBONE 隧道。

这一页我们来看一个更具体的 HBONE 协议示例。我们都知道，HBONE 使用的是 HTTP/2 CONNECT 隧道 + mTLS 加密的方式，把原本 TCP 流量封装进来。 在这个示例里，假设 ztunnel A 需要把流量发送给 目标节点 B，我们可以看到外层的 TCP 连接其实是从 ztunnel_A_IP:52368 连到 Node_B_IP:15008。这是 ztunnel A 和 ztunnel B 之间的隧道端口，15008 就是 HBONE 监听端口。 进入到 HTTP/2 层后，就会有一个 CONNECT 请求，里面的 :authority 显示的是 Pod_B_IP:9080，表示实际上要连到 Pod B 的 9080 端口。x-envoy-original-dst-host 里也能看出相同信息。 同时我们看到了一些自定义头，比如 x-forwarded-proto、x-istio-attributes 等，用来给目标 ztunnel 或后续代理带去更多上下文和安全验证信息。 可以把这个理解为：在 HTTP/2 CONNECT 之上，流量就像加了一个“内层”隧道，把应用层的请求（例如 /api/v1/users?id=123）封装在这里面，然后在 ztunnel B 端解封装并转发到真实的 Pod B。 整个过程对应用来说是透明的，但对我们来说，通过查看这种 CONNECT 请求头，可以了解 Ambient 模式如何在 HTTP/2 层做流量路由和身份认证。这就是为什么说 HBONE 比传统的 Sidecar-to-Sidecar通信更加灵活，也更便于做 mTLS 以及 L7 扩展。

如果源 Pod 和目标 Pod 恰好在同一个节点上，流量会走 ztunnel 的 L4 加密流程。 这里显示，ztunnel 是使用 DaemonSet 部署在每个节点上的，并且使用了host Network，共享主机的网络。Istio CNI 将 Pod 的出站流量拦截到 ztunnel的15001端口，如果源和目的 pod 在同一个节点上，ztunnel 直接在内部完成加解密后将流量发送到目的地 pod。 如果需要 L7 的流量处理，比如鉴权，ztunnel 就会与 Waypoint 代理建立 HBONE 隧道，经过 Waypoint 代理的转发到目的 Pod。

这是跨节点的情况，也就是最常见的场景： 源节点的 ztunnel 把流量通过 HBONE 隧道加密后发给目标节点的 ztunnel； 目标节点 ztunnel 解封装，再把明文流量递给目标 Pod。 只要是纯 L4 无需 L7，就不必加一层 Waypoint，减少了代理链路。

当我们需要 L7 处理时，流量就会多经过一下 Waypoint。也就是： 源 ztunnel 先把流量隧道给 Waypoint； Waypoint 在 HTTP 层做鉴权、路由等； Waypoint 再用 HBONE 把流量发给目标 ztunnel； 目标 ztunnel 解封装后给目标 Pod。 这个流程比 L4 多了一次代理，但好处是只有特定流量才会被 L7 代理解析，减少不必要的开销。

对于非 Istio网格内部的流量，通过 Pod IP和端口直接访问 Pod时，为了防止这些流量逃出 ztunnel的掌控，也需要拦截这些流量。如果流量是访问的应用端口，通过判断数据包上是否带有 0x539 标记，如果没有，则将其转发到 ztunnel 监听的 15006 明文端口，经 ztunnel 处理后会带上 0x539 标记，然后就可以访问应用的目标端口了；如果流量的目的端口是 15008，那么实际上就会被 ztunnel 监听和处理，判断 HBONE 协议。

小结一下： L4 场景：只走 ztunnel，性能好，资源消耗更低； L7 场景：ztunnel + Waypoint，多一层处理，但能实现完整的 HTTP/gRPC 策略。 这样比原先在所有 Pod 都注入 Sidecar 做 L7，更具弹性和可控性。

有了对 Ambient 的了解后，我们还是得和原有的 Sidecar 模式做对比，来看看哪些功能还不完善，哪些场景更适合 Ambient。

这里列出了一些 Ambient 模式的限制点： Sidecar 模式可以对每个 Pod 做 EnvoyFilter、WASM 插件等精准定制，但 Ambient 模式下，如果已经把代理抽到节点层或 Waypoint，就无法对单个 Pod 的代理做深度改造。 多集群、多网络、以及 VM 工作负载支持，目前还在逐步完善中。 这意味着如果你的生产环境依赖这些功能，短期内可能还需要保留 Sidecar。

我们把 Sidecar 与 Ambient 的差别列在一个表里： 代理位置：Sidecar 在每 Pod，Ambient 是节点或命名空间一级； 资源消耗：Sidecar 总体更高，Ambient 可以共享； 功能完整度：Sidecar 更成熟，Ambient 还有一些高级功能不完备； 性能：L4 场景 Ambient 更快，L7 需要经过 Waypoint，但依然比每个 Pod Sidecar 占用更少的资源。 大家可以根据自己团队需求做取舍。

如果你已经在生产上跑 Sidecar 并且依赖很多 EnvoyFilter、自定义插件，短期内没必要着急迁移； 如果你手上有规模很大的集群、对运维和资源成本很敏感，并且大部分流量只需要 L4 安全，那么不妨去试一下 Ambient 模式； 也可以做个混合部署，比如关键服务还用 Sidecar，其他业务服务切到 Ambient，这就要求你在一个网格里同时管理两套模式，会更复杂，但也更灵活。

好的，最后我们来总结一下 Ambient Mode 的优缺点，以及当前适合哪些场景。然后再进入 Q&A 环节。

这四点就是我们今天讨论的核心： 1）Ambient Mode 带来的最大好处就是“去 Sidecar”，节省资源并简化运维； 2）采用 ztunnel + Waypoint 的分层设计，L7 流量才用 Waypoint。 3）目前 Istio 已宣称 Ambient Mode GA，但多集群、VM 等还不够完善，你得考虑风险； 4）最典型适合大规模、主要跑 TCP 流量的集群，可以先行试点。 如果你对安全隔离、可观测可控性有更高要求，再考虑合适的模式或混合部署。

今天的内容就到这里，非常感谢大家的聆听！ 你们可以在我的个人网站 jimmysong.io 获取更多分享和资料。 如果大家有什么问题，欢迎现在提问，或者会后与我交流。谢谢！