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

為什么關注 Ambient Mode？

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

讓我們看看當前服務網(wǎng)格面臨的一些問題和挑戰(zhàn)。

服務網(wǎng)格的挑戰(zhàn)

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

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

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

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

服務網(wǎng)格的幾種部署模式

代理的位置

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

? Sidecar：每個 Pod 內(nèi)跑一個 Envoy。

? Ambient：將代理從 Pod 中剝離到節(jié)點級（即本篇要談的模式）。

? Cilium Mesh：利用 eBPF 在內(nèi)核空間做 L4，然后結合 Envoy 提供 L7 功能。

? gRPC：直接將網(wǎng)格能力集成到 SDK 中。

這些模式在功能、安全、性能和管理復雜度上都有不同的側重。Istio Ambient Mode 則是針對 Sidecar 帶來的高資源消耗和運維成本，而提出的新嘗試。

Ambient Mode 的誕生

? Istio 的新一代架構，移除 Sidecar，通過 ztunnel + Waypoint Proxy 實現(xiàn)數(shù)據(jù)面的輕量化。

? 節(jié)省資源、降低運維復雜度。

? 依然支持 mTLS、策略管控，并為需要 L7 功能的流量提供可選的 Waypoint Proxy。

部署模式象限

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

Istio Ambient Mode 核心概念

接下來我們正式進入第二部分，深入看看 Ambient Mode 的具體組件，包括 ztunnel、Waypoint Proxy 以及 Istio CNI 在其中扮演的角色。

Ambient Mode 的核心組件

1. ztunnel (L4)

? 以 Node 級代理的方式運行

? 負責 透明流量攔截、mTLS 加密

? 適用于大部分只需 L4 轉(zhuǎn)發(fā)的流量

2. Waypoint Proxy (L7)

? 可選部署（根據(jù)命名空間 / Service / Pod 粒度靈活配置）

? 處理 HTTP / gRPC 等高級功能（鑒權、路由、可觀測等）

3. Istio CNI

? 取代 istio-init 容器，負責流量劫持

? 兼容 Sidecar 模式和 Ambient 模式

? 允許在非特權模式下為 Pod 設置流量重定向

Ambient 模式整體架構

Istio Ambient 模式架構

在 Ambient 模式下，Istio 數(shù)據(jù)面可分為兩層：

1. 安全層 (ztunnel)：每個節(jié)點部署一個輕量級 L4 代理。

2. 可選的 L7 層 (Waypoint Proxy)：需要 HTTP/gRPC 代理時才部署。

Control Plane 依然由 Istiod 提供，主要負責給 ztunnel、Waypoint 下發(fā)配置和證書。

Waypoint Proxy 部署策略

? Namespace 級（默認）：適用于該命名空間下所有 Workload

? Service 級：僅特定關鍵服務需要 L7

? Pod 級：更精細化控制

? 跨 Namespace：可以使用 Gateway 資源共享

Istio CNI

? 流量攔截：取代 istio-init 容器，使安裝更加清晰簡潔。

? 支持兩種模式：兼容 Sidecar 模式 和 Ambient 模式。

? 非特權模式兼容性：允許 Pod 運行在無特權模式下，增強安全性。

? CNI 鏈接（Chaining）：通過添加 Istio CNI 擴展節(jié)點的 CNI 配置。

? Pod 內(nèi)部流量重定向（Ambient 模式）：

在 Pod 的網(wǎng)絡命名空間內(nèi)使用 iptables REDIRECT 規(guī)則。

創(chuàng)建 Pod 內(nèi)部的 socket 以攔截和代理流量。

這張圖簡單示意了 Istio CNI 如何與 Kubernetes 本身的網(wǎng)絡插件（如 Calico、Cilium 等）組合在一起。它修改了本機的 CNI 配置，增加了 CNI 鏈，在 Kubernetes 分配完 Pod IP 后，緊接著就會執(zhí)行 Istio CNI 的攔截邏輯，把網(wǎng)絡流量規(guī)則注入到 Pod netns。并且為不同模式中 Pod 配置不同的 iptables 規(guī)則。這樣就與原本的 CNI 配置（包括網(wǎng)絡策略）形成一個鏈式流程，不會相互沖突。

Istio CNI 插件的運行步驟

Istio CNI 插件工作原理

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

圖片

Istio CNI 插件工作原理

1. 它會進入 Pod 的網(wǎng)絡命名空間，創(chuàng)建一套 iptables 規(guī)則，把流量劫持到 ztunnel 監(jiān)聽的 socket 上。

2. 不再需要在每個 Pod 里注入 init 容器，也不需要特權權限，這就讓整體部署更干凈、也更安全。

3. ztunnel會在pod的網(wǎng)絡命名空間中建立一個socket，并且為節(jié)點上的每個pod都會建立一個。

流量路徑與關鍵機制

介紹完組件之后，我們來看看最核心的“流量路徑”。zTunnel 和 Waypoint 究竟是怎么攔截并轉(zhuǎn)發(fā)流量的？我們會從透明流量攔截、HBONE 協(xié)議等角度進行解析。

透明流量攔截

在 Ambient 模式中，Istio CNI 會在 Pod 網(wǎng)絡命名空間中注入 iptables 規(guī)則，將出站流量透明攔截到所在節(jié)點的 ztunnel 進程。之后由 ztunnel 決定是直接進行 L4 轉(zhuǎn)發(fā)，還是將流量轉(zhuǎn)發(fā)至 Waypoint Proxy 做進一步的 L7 處理。

如圖所示，Kubelet 在節(jié)點上啟動了一個 Pod，這個事件被 Istio CNI Agent 監(jiān)聽到，Istio CNI Agent 進入 Pod 的網(wǎng)絡空間，設置 iptables 規(guī)則將流量重定向到本地 socket，并將 Pod 的文件描述符（FD）發(fā)送為 ztunnel。ztunnel 獲取到 FD 之后就可以在 Pod 的網(wǎng)絡空間中創(chuàng)建 socket。

Pod 在發(fā)送流量時，本該直連目標地址，但是 iptables 規(guī)則會把它攔截到本節(jié)點的 ztunnel 進程里，然后 ztunnel 決定這條流量需不需要交給 Waypoint 做 L7 代理。如果不需要，就直接在 L4 層把它加密轉(zhuǎn)發(fā)到目標 Pod；如果要 L7，例如鑒權，就再把流量隧道給 Waypoint。

透明流量攔截

數(shù)據(jù)包生命周期概覽

1. Pod → ztunnel：Pod 的流量先被 CNI 攔截到本節(jié)點 ztunnel。

2. ztunnel：解析目標地址并進行 mTLS 加密。

3. （如需要 L7 策略）ztunnel → Waypoint Proxy：HTTP 鑒權、路由等操作。

4. Waypoint Proxy：完成 L7 處理后，再發(fā)回 ztunnel。

5. ztunnel：解封裝或繼續(xù)轉(zhuǎn)發(fā)至目標節(jié)點 ztunnel。

6. 到達目標 Pod：目標節(jié)點 ztunnel 最終將流量交給目標 Pod。

HBONE 協(xié)議

Ambient 模式中，zTunnel 與 Waypoint 之間使用 HBONE (HTTP/2 + CONNECT) 協(xié)議來建立安全隧道，實現(xiàn) mTLS 加密 和多路復用，減少額外的連接開銷，簡化代理轉(zhuǎn)發(fā)流程。

HBONE 協(xié)議

下面是一個簡化的 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 需要把流量發(fā)送給 目標節(jié)點 B，我們可以看到外層的 TCP 連接其實是從 ztunnel_A_IP:52368 連到 Node_B_IP:15008。這是 ztunnel A 和 ztunnel B 之間的隧道端口，15008 就是 HBONE 監(jiān)聽端口。

進入到 HTTP/2 層后，就會有一個 CONNECT 請求，里面的 :authority 顯示的是 Pod_B_IP:9080，表示實際上要連到 Pod B 的 9080 端口。x-envoy-original-dst-host 里也能看出相同信息。

同時我們看到了一些自定義頭，比如 x-forwarded-proto、x-istio-attributes 等，用來給目標 ztunnel 或后續(xù)代理帶去更多上下文和安全驗證信息。

可以把這個理解為：在 HTTP/2 CONNECT 之上，流量就像加了一個“內(nèi)層”隧道，把應用層的請求（例如 /api/v1/users?id=123）封裝在這里面，然后在 ztunnel B 端解封裝并轉(zhuǎn)發(fā)到真實的 Pod B。

整個過程對應用來說是透明的，但對我們來說，通過查看這種 CONNECT 請求頭，可以了解 Ambient 模式如何在 HTTP/2 層做流量路由和身份認證。這就是為什么說 HBONE 比傳統(tǒng)的 Sidecar-to-Sidecar通信更加靈活，也更便于做 mTLS 以及 L7 擴展。

同節(jié)點上的加密流量

如果源 Pod 和目標 Pod 恰好在同一個節(jié)點上，流量會走 ztunnel 的 L4 加密流程。這里顯示，ztunnel 是使用 DaemonSet 部署在每個節(jié)點上的，并且使用了host Network，共享主機的網(wǎng)絡。Istio CNI 將 Pod 的出站流量攔截到 ztunnel的15001端口，如果源和目的 pod 在同一個節(jié)點上，ztunnel 直接在內(nèi)部完成加解密后將流量發(fā)送到目的地 pod。

如果需要 L7 的流量處理，比如鑒權，ztunnel 就會與 Waypoint 代理建立 HBONE 隧道，經(jīng)過 Waypoint 代理的轉(zhuǎn)發(fā)到目的 Pod。

同節(jié)點上的加密流量

跨節(jié)點的加密流量（L4）

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

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

跨節(jié)點的加密流量（L4）

跨節(jié)點的加密流量（L7）

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

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

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

? Waypoint 再用 HBONE 把流量發(fā)給目標 ztunnel；

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

跨節(jié)點的加密流量（L7）

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

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

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

來自非mesh內(nèi)部的流量

L4 與 L7 流量差異

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

Ambient Mode vs. Sidecar Mode

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

Ambient 模式的限制

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

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

? 多集群、多網(wǎng)絡、以及 虛擬機 工作負載的支持還不夠完善，生產(chǎn)環(huán)境使用需謹慎。

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

功能與差異對比

選擇建議

1. 若已有 Sidecar 架構且依賴大量成熟特性：可先繼續(xù)使用 Sidecar。

2. 追求 資源節(jié)省、運維簡化 且大部分流量僅需 L4：可嘗試 Ambient Mode。

3. 如果部分應用仍需保留 Sidecar，可考慮 混合部署，但需額外規(guī)劃 Sidecar / Ambient 的邊界和策略。

總結

好的，最后我們來總結一下 Ambient Mode 的優(yōu)缺點，以及當前適合哪些場景。

核心要點回顧

1. Ambient Mode：通過移除 Sidecar，降低每個 Pod 的代理負擔，顯著降低資源和運維成本。

2. ztunnel + Waypoint 架構：需要 L7 功能時才啟用 Waypoint，其他流量以 L4 方式快速轉(zhuǎn)發(fā)。

3. 雖然官方已宣布 Ambient Mode GA，但對于 多集群 / VM / 多網(wǎng)絡 等仍需進一步觀察、測試。

4. 適用場景：大規(guī)模集群 + 主要以 L4 流量為主，對資源和管理要求高的團隊可以重點關注。