超越 Sidecar：深入解析 Istio Ambient Mode 的流量机制与成本效益

本文将带大家了解 Ambient Mode 的出现背景、核心组件、流量路径机制以及与现有 Sidecar 模式的对比，从而帮助你快速评估并上手这项新特性。

  • 2025/03/22
  • Istio
  • 21 分钟
  • 4656 字
版权声明
本文为 Jimmy Song 原创。转载请注明来源： https://jimmysong.io/blog/beyond-sidecar/
查看本文大纲

欢迎阅读我的这篇博客——“超越 Sidecar：深入解析 Istio Ambient Mode 的流量机制与成本效益”。本文内容源自我在 KCD 北京的一次演讲。主要探讨的是 Istio 全新推出的一种数据面模式 —— Ambient Mode。它的核心理念是去除 Sidecar，减少资源开销与运维复杂度。本文将带大家了解 Ambient Mode 的出现背景、核心组件、流量路径机制以及与现有 Sidecar 模式的对比，从而帮助你快速评估并上手这项新特性。

点击查看幻灯片。

为什么关注 Ambient Mode？

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

让我们看看当前服务网格面临的一些问题和挑战。

服务网格的挑战

  • Sidecar 代理带来的 资源开销 和 运维复杂度
  • 升级 或 重启 Envoy 时，常常需要连带重启所有 Pod
  • 越来越多对 高性能、低成本 的需求

思考：有没有一种方式在保留服务网格核心能力（安全、可观测、流量控制）的同时，减少对每个 Pod 的侵入和额外资源消耗？

服务网格的几种部署模式

image
代理的位置

服务网格架构一直在探索代理部署位置的多种可能性。例如：

  • Sidecar：每个 Pod 内跑一个 Envoy。
  • Ambient：将代理从 Pod 中剥离到节点级（即本篇要谈的模式）。
  • Cilium Mesh：利用 eBPF 在内核空间做 L4，然后结合 Envoy 提供 L7 功能。
  • gRPC：直接将网格能力集成到 SDK 中。

这些模式在功能、安全、性能和管理复杂度上都有不同的侧重。Istio Ambient Mode 则是针对 Sidecar 带来的高资源消耗和运维成本，而提出的新尝试。

Ambient Mode 的诞生

  • Istio 的新一代架构，移除 Sidecar，通过 ztunnel + Waypoint Proxy 实现数据面的轻量化。
  • 节省资源、降低运维复杂度。
  • 依然支持 mTLS、策略管控，并为需要 L7 功能的流量提供可选的 Waypoint Proxy。
image
部署模式象限

以下表格是对比常见服务网格部署模式的一些简要特点：

模式 安全性 效率 可管理性 性能
Sidecar 模式 高安全性，隔离的代理 资源使用率高 集中化管理但较为复杂 增加一定延迟
Ambient 模式 通过 ztunnel 提供安全性，仍在发展中 更高效，共享代理 管理更简单但功能在完善中 良好；跨可用区时需注意网络开销
Cilium mesh 中等安全性，基于 eBPF 内核级效率 配置复杂 可视场景不同而异
gRPC 应用集成安全，依赖应用自身 高效 更新管理复杂 低延迟，适用于实时场景

Istio Ambient Mode 核心概念

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

Ambient Mode 的核心组件

  1. ztunnel (L4)
    • 以 Node 级代理的方式运行
    • 负责 透明流量拦截、mTLS 加密
    • 适用于大部分只需 L4 转发的流量
  2. Waypoint Proxy (L7)
    • 可选部署（根据命名空间 / Service / Pod 粒度灵活配置）
    • 处理 HTTP / gRPC 等高级功能（鉴权、路由、可观测等）
  3. Istio CNI
    • 取代 istio-init 容器，负责流量劫持
    • 兼容 Sidecar 模式和 Ambient 模式
    • 允许在非特权模式下为 Pod 设置流量重定向

Ambient 模式整体架构

image
Istio Ambient 模式架构

在 Ambient 模式下，Istio 数据面可分为两层：

  1. 安全层 (ztunnel)：每个节点部署一个轻量级 L4 代理。
  2. 可选的 L7 层 (Waypoint Proxy)：需要 HTTP/gRPC 代理时才部署。

Control Plane 依然由 Istiod 提供，主要负责给 ztunnel、Waypoint 下发配置和证书。

Waypoint Proxy 部署策略

  • Namespace 级（默认）：适用于该命名空间下所有 Workload
  • Service 级：仅特定关键服务需要 L7
  • Pod 级：更精细化控制
  • 跨 Namespace：可以使用 Gateway 资源共享

Istio CNI

  • 流量拦截：取代 istio-init 容器，使安装更加清晰简洁。
  • 支持两种模式：兼容 Sidecar 模式 和 Ambient 模式。
  • 非特权模式兼容性：允许 Pod 运行在无特权模式下，增强安全性。
  • CNI 链接（Chaining）：通过添加 Istio CNI 扩展节点的 CNI 配置。
  • Pod 内部流量重定向（Ambient 模式）：
    • 在 Pod 的网络命名空间内使用 iptables REDIRECT 规则。
    • 创建 Pod 内部的 socket 以拦截和代理流量。

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

image
Istio CNI 插件的运行步骤

Istio CNI 插件工作原理

这张图详细描绘了当 Pod 启动时，Istio CNI 会怎么做：

image
Istio CNI 插件工作原理
  1. 它会进入 Pod 的网络命名空间，创建一套 iptables 规则，把流量劫持到 ztunnel 监听的 socket 上。
  2. 不再需要在每个 Pod 里注入 init 容器，也不需要特权权限，这就让整体部署更干净、也更安全。
  3. ztunnel会在pod的网络命名空间中建立一个socket，并且为节点上的每个pod都会建立一个。

流量路径与关键机制

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

透明流量拦截

在 Ambient 模式中，Istio CNI 会在 Pod 网络命名空间中注入 iptables 规则，将出站流量透明拦截到所在节点的 ztunnel 进程。之后由 ztunnel 决定是直接进行 L4 转发，还是将流量转发至 Waypoint Proxy 做进一步的 L7 处理。

如图所示，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。

image
透明流量拦截

数据包生命周期概览

  1. Pod → ztunnel：Pod 的流量先被 CNI 拦截到本节点 ztunnel。
  2. ztunnel：解析目标地址并进行 mTLS 加密。
  3. （如需要 L7 策略）ztunnel → Waypoint Proxy：HTTP 鉴权、路由等操作。
  4. Waypoint Proxy：完成 L7 处理后，再发回 ztunnel。
  5. ztunnel：解封装或继续转发至目标节点 ztunnel。
  6. 到达目标 Pod：目标节点 ztunnel 最终将流量交给目标 Pod。

HBONE 协议

Ambient 模式中，zTunnel 与 Waypoint 之间使用 HBONE (HTTP/2 + CONNECT) 协议来建立安全隧道，实现 mTLS 加密 和多路复用，减少额外的连接开销，简化代理转发流程。

image
HBONE 协议

下面是一个简化的 HBONE CONNECT 请求示例，利用 x-envoy-original-dst-host、x-istio-auth-userinfo 等头信息来传递路由和身份认证所需上下文。

:method: CONNECT
:scheme: https
:authority: Pod_B_IP:9080
:path: /api/v1/users?id=123
x-envoy-original-dst-host: Pod_B_IP:9080
x-forwarded-proto: hbone
x-istio-attributes: ...
...

在这个示例里，假设 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。

image
同节点上的加密流量

跨节点的加密流量（L4）

这是跨节点的情况，也就是最常见的场景：

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

image
跨节点的加密流量（L4）

跨节点的加密流量（L7）

当我们需要 L7 处理时，流量就会多经过一下 Waypoint。也就是：

  • 源 ztunnel 先把流量隧道给 Waypoint；
  • Waypoint 在 HTTP 层做鉴权、路由等；
  • Waypoint 再用 HBONE 把流量发给目标 ztunnel；
  • 目标 ztunnel 解封装后给目标 Pod。
image
跨节点的加密流量（L7）

这个流程比 L4 多了一次代理，但好处是只有特定流量才会被 L7 代理解析，减少不必要的开销。

兜底流量（防止流量逃逸）

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

image
来自非mesh内部的流量

L4 与 L7 流量差异

流量类型 处理位置 示例场景
L4 ztunnel（透明转发） TCP 级别流量，不需应用层策略
L7 ztunnel → Waypoint Proxy HTTP/gRPC 需要鉴权、熔断、路由、可观测等高级功能

对于大部分只需 TCP 层加密和转发的流量，Ambient Mode 仅通过 ztunnel 即可；只有在需要 HTTP 层策略时才会额外经过 Waypoint。

Ambient Mode vs. Sidecar Mode

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

Ambient 模式的限制

与传统 Sidecar 模式相比，Ambient 目前仍有一些不完善之处：

  • 在混合使用 Sidecar 与 Ambient 时，难以对单个 Pod 做精准代理定制（例如 EnvoyFilter）。
  • 多集群、多网络、以及 虚拟机 工作负载的支持还不够完善，生产环境使用需谨慎。
  • 一些深度定制（例如 WASM 插件）目前无法在 Ambient 下直接一对一实现。

功能与差异对比

指标 Sidecar 模式 Ambient 模式
代理位置 每个 Pod 都运行 Envoy Sidecar Node 级 ztunnel + 可选的 Waypoint Proxy
资源开销 在大规模场景下 CPU/内存消耗相对更高 相对更低：代理共享在节点/命名空间级
运维复杂度 升级 Sidecar 需滚动更新所有关联 Pod，操作较繁琐 部署/升级集中在少数组件（ztunnel / Waypoint），运维更简单
性能 每个 Pod 都有 Envoy，使得隔离性更强，但整体有额外代理开销 L4 性能较好，L7 场景需要多经过一次 Waypoint 转发
功能完整度 成熟稳定，支持多集群、VM、混合网络 尚在演进，多网络、VM 等高级场景支持仍在完善
典型使用场景 注重严格隔离或依赖特定的 EnvoyFilter、WASM 插件等深度定制 大规模集群、需要轻量化管理且大部分流量以 L4 为主的场景

选择建议

  1. 若已有 Sidecar 架构且依赖大量成熟特性：可先继续使用 Sidecar。
  2. 追求 资源节省、运维简化 且大部分流量仅需 L4：可尝试 Ambient Mode。
  3. 如果部分应用仍需保留 Sidecar，可考虑 混合部署，但需额外规划 Sidecar / Ambient 的边界和策略。

总结

好的，最后我们来总结一下 Ambient Mode 的优缺点，以及当前适合哪些场景。

核心要点回顾

  1. Ambient Mode：通过移除 Sidecar，降低每个 Pod 的代理负担，显著降低资源和运维成本。
  2. ztunnel + Waypoint 架构：需要 L7 功能时才启用 Waypoint，其他流量以 L4 方式快速转发。
  3. 虽然官方已宣布 Ambient Mode GA，但对于 多集群 / VM / 多网络 等仍需进一步观察、测试。
  4. 适用场景：大规模集群 + 主要以 L4 流量为主，对资源和管理要求高的团队可以重点关注。

你也可以通过 jimmysong.io 网站找到更多云原生相关的文章和实践分享。如果对此文或 Istio 有任何疑问，欢迎给我留言或在社区中交流。谢谢！

最后更新于 2025/03/22

Istio Service Mesh KCD Sidecar Ambient