本文內容源自我在 KCD 北京的一次演講。主要探討的是 Istio 全新推出的一種數據面模式 —— Ambient Mode。它的核心理念是去除 Sidecar，減少資源開銷與運維復雜度。本文將帶大家了解 Ambient Mode 的出現背景、核心組件、流量路徑機制以及與現有 Sidecar 模式的對比，從而幫助你快速評估并上手這項新特性。

為什么關注 Ambient Mode？

首先，我們來思考一個問題：為什么要關注、甚至嘗試這種新模式？Sidecar 在服務網格里一直都用得好好的，為什么要“去 Sidecar”呢？

讓我們看看當前服務網格面臨的一些問題和挑戰。

服務網格的挑戰

? Sidecar 代理帶來的 資源開銷 和 運維復雜度

? 升級 或 重啟 Envoy 時，常常需要連帶重啟所有 Pod

? 越來越多對 高性能、低成本 的需求

思考：有沒有一種方式在保留服務網格核心能力（安全、可觀測、流量控制）的同時，減少對每個 Pod 的侵入和額外資源消耗？

服務網格的幾種部署模式

代理的位置

服務網格架構一直在探索代理部署位置的多種可能性。例如：

? 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。

部署模式象限

以下表格是對比常見服務網格部署模式的一些簡要特點：

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 模式整體架構

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 配置（包括網絡策略）形成一個鏈式流程，不會相互沖突。

Istio CNI 插件的運行步驟

Istio CNI 插件工作原理

這張圖詳細描繪了當 Pod 啟動時，Istio CNI 會怎么做：

圖片

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。

透明流量攔截

數據包生命周期概覽

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 加密 和多路復用，減少額外的連接開銷，簡化代理轉發流程。

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。

同節點上的加密流量

跨節點的加密流量（L4）

這是跨節點的情況，也就是最常見的場景：

源節點的 ztunnel 把流量通過 HBONE 隧道加密后發給目標節點的 ztunnel；目標節點 ztunnel 解封裝，再把明文流量遞給目標 Pod。只要是純 L4 無需 L7，就不必加一層 Waypoint，減少了代理鏈路。

跨節點的加密流量（L4）

跨節點的加密流量（L7）

當我們需要 L7 處理時，流量就會多經過一下 Waypoint。也就是：

? 源 ztunnel 先把流量隧道給 Waypoint；

? Waypoint 在 HTTP 層做鑒權、路由等；

? Waypoint 再用 HBONE 把流量發給目標 ztunnel；

? 目標 ztunnel 解封裝后給目標 Pod。

跨節點的加密流量（L7）

這個流程比 L4 多了一次代理，但好處是只有特定流量才會被 L7 代理解析，減少不必要的開銷。

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

對于非 Istio網格內部的流量，通過 Pod IP和端口直接訪問 Pod時，為了防止這些流量逃出 ztunnel的掌控，也需要攔截這些流量。如果流量是訪問的應用端口，通過判斷數據包上是否帶有 0x539 標記，如果沒有，則將其轉發到 ztunnel 監聽的 15006 明文端口，經 ztunnel 處理后會帶上 0x539 標記，然后就可以訪問應用的目標端口了；如果流量的目的端口是 15008，那么實際上就會被 ztunnel 監聽和處理，判斷 HBONE 協議。

來自非mesh內部的流量

L4 與 L7 流量差異

對于大部分只需 TCP 層加密和轉發的流量，Ambient Mode 僅通過 ztunnel 即可；只有在需要 HTTP 層策略時才會額外經過 Waypoint。

Ambient Mode vs. Sidecar Mode

有了對 Ambient 的了解后，我們還是得和原有的 Sidecar 模式做對比，來看看哪些功能還不完善，哪些場景更適合 Ambient。

Ambient 模式的限制

與傳統 Sidecar 模式相比，Ambient 目前仍有一些不完善之處：

? 在混合使用 Sidecar 與 Ambient 時，難以對單個 Pod 做精準代理定制（例如 EnvoyFilter）。

? 多集群、多網絡、以及 虛擬機 工作負載的支持還不夠完善，生產環境使用需謹慎。

? 一些深度定制（例如 WASM 插件）目前無法在 Ambient 下直接一對一實現。

功能與差異對比

選擇建議

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 流量為主，對資源和管理要求高的團隊可以重點關注。