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

為什么關(guān)注 Ambient Mode？

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

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

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

? Sidecar 代理帶來(lái)的 資源開(kāi)銷 和 運(yùn)維復(fù)雜度

? 升級(jí) 或 重啟 Envoy 時(shí)，常常需要連帶重啟所有 Pod

? 越來(lái)越多對(duì) 高性能、低成本 的需求

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

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

代理的位置

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

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

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

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

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

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

Ambient Mode 的誕生

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

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

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

部署模式象限

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

Istio Ambient Mode 核心概念

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

Ambient Mode 的核心組件

1. ztunnel (L4)

? 以 Node 級(jí)代理的方式運(yùn)行

? 負(fù)責(zé) 透明流量攔截、mTLS 加密

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

2. Waypoint Proxy (L7)

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

? 處理 HTTP / gRPC 等高級(jí)功能（鑒權(quán)、路由、可觀測(cè)等）

3. Istio CNI

? 取代 istio-init 容器，負(fù)責(zé)流量劫持

? 兼容 Sidecar 模式和 Ambient 模式

? 允許在非特權(quán)模式下為 Pod 設(shè)置流量重定向

Ambient 模式整體架構(gòu)

Istio Ambient 模式架構(gòu)

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

1. 安全層 (ztunnel)：每個(gè)節(jié)點(diǎn)部署一個(gè)輕量級(jí) L4 代理。

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

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

Waypoint Proxy 部署策略

? Namespace 級(jí)（默認(rèn)）：適用于該命名空間下所有 Workload

? Service 級(jí)：僅特定關(guān)鍵服務(wù)需要 L7

? Pod 級(jí)：更精細(xì)化控制

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

Istio CNI

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

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

? 非特權(quán)模式兼容性：允許 Pod 運(yùn)行在無(wú)特權(quán)模式下，增強(qiáng)安全性。

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

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

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

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

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

Istio CNI 插件的運(yùn)行步驟

Istio CNI 插件工作原理

這張圖詳細(xì)描繪了當(dāng) Pod 啟動(dòng)時(shí)，Istio CNI 會(huì)怎么做：

圖片

Istio CNI 插件工作原理

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

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

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

流量路徑與關(guān)鍵機(jī)制

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

透明流量攔截

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

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

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

透明流量攔截

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

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

2. ztunnel：解析目標(biāo)地址并進(jìn)行 mTLS 加密。

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

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

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

6. 到達(dá)目標(biāo) Pod：目標(biāo)節(jié)點(diǎn) ztunnel 最終將流量交給目標(biāo) Pod。

HBONE 協(xié)議

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

HBONE 協(xié)議

下面是一個(gè)簡(jiǎn)化的 HBONE CONNECT 請(qǐng)求示例，利用 x-envoy-original-dst-host、x-istio-auth-userinfo 等頭信息來(lái)傳遞路由和身份認(rèn)證所需上下文。

: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: ...
...

在這個(gè)示例里，假設(shè) ztunnel A 需要把流量發(fā)送給 目標(biāo)節(jié)點(diǎn) B，我們可以看到外層的 TCP 連接其實(shí)是從 ztunnel_A_IP:52368 連到 Node_B_IP:15008。這是 ztunnel A 和 ztunnel B 之間的隧道端口，15008 就是 HBONE 監(jiān)聽(tīng)端口。

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

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

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

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

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

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

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

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

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

這是跨節(jié)點(diǎn)的情況，也就是最常見(jiàn)的場(chǎng)景：

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

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

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

當(dāng)我們需要 L7 處理時(shí)，流量就會(huì)多經(jīng)過(guò)一下 Waypoint。也就是：

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

? Waypoint 在 HTTP 層做鑒權(quán)、路由等；

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

? 目標(biāo) ztunnel 解封裝后給目標(biāo) Pod。

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

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

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

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

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

L4 與 L7 流量差異

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

Ambient Mode vs. Sidecar Mode

有了對(duì) Ambient 的了解后，我們還是得和原有的 Sidecar 模式做對(duì)比，來(lái)看看哪些功能還不完善，哪些場(chǎng)景更適合 Ambient。

Ambient 模式的限制

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

? 在混合使用 Sidecar 與 Ambient 時(shí)，難以對(duì)單個(gè) Pod 做精準(zhǔn)代理定制（例如 EnvoyFilter）。

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

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

功能與差異對(duì)比

選擇建議

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

2. 追求 資源節(jié)省、運(yùn)維簡(jiǎn)化 且大部分流量?jī)H需 L4：可嘗試 Ambient Mode。

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

總結(jié)

好的，最后我們來(lái)總結(jié)一下 Ambient Mode 的優(yōu)缺點(diǎn)，以及當(dāng)前適合哪些場(chǎng)景。

核心要點(diǎn)回顧

1. Ambient Mode：通過(guò)移除 Sidecar，降低每個(gè) Pod 的代理負(fù)擔(dān)，顯著降低資源和運(yùn)維成本。

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

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

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