超越Sidecar：深入解析Istio Ambient Mode的流量機制與成本效率

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

 

為什麼要關注環境模式？

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

 

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

 

服務網格的挑戰

• Sidecar代理商帶來的資源開銷與運輸複雜度

 

• 升級或重新啟動 Envoy 時，通常需要連帶重新啟動所有 Pod

 

• 越來越多對效能、損耗的需求

 

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

 

服務網格的幾種部署模式

 

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

 

• Sidecar：每個Pod內運行一個Envoy。

 

• Ambient：將代理人從Pod分割到節點級（即本篇要談的模式）。

 

• Cilium Mesh：利用eBPF在內核空間做L4，然後結合Envoy提供L7功能。

 

• gRPC：直接將網格能力整合到SDK 中。

 

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

 

環境模式的誕生

• Istio 的新一代架構，移除了 Sidecar，透過 ztunnel + Waypoint Proxy 實現資料面的輕量化。

 

• 節省資源、降低運輸複雜度。

 

• 仍然支援mTLS、策略管控，並為需要L7功能的流量提供可選的Waypoint Proxy。

 

部署模式象限

 

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

 

Istio Ambient 模式核心概念

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

 

環境模式的核心元件

1.z隧道（L4）

 

• 以節點級代理的方式運行

 

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

 

• 適用於大多數 L4 轉送的流量

 

2. 航點代理（L7）

 

• 選擇性配置（根據命名空間/Service/Pod 粒度靈活配置）

 

• 處理HTTP / gRPC等高階功能（鑑權、路由、可入境等）

 

3.Istio CNI

 

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

 

• 相容於Sidecar模式和Ambient模式

 

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

 

Ambient模式整體架構

Istio Ambient 模式架構

Istio Ambient 模式架構

 

在 Ambient 模式下，Istio 資料面可分為兩層：

 

1.安全層（ztunnel）：每個節點部署一個輕量級L4代理程式。

 

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

 

Control Plane 仍然由 Istiod 提供，主要負責給 ztunnel、Waypoint 下發配置和憑證。

 

Waypoint Proxy部署策略

• 命名空間等級（預設）：適用於該命名空間下所有工作負載

 

• 服務等級：僅特定關鍵服務需要L7

 

• Pod等級：更精細化控制

 

• 跨命名空間：可使用網關資源共用

 

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 外掛程式工作原理

這張圖詳細繪製了當 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 規則將流量重新導向到本機套接字，將 Pod 的檔案轉送到本機套接字，將 Pod 的檔案轉送到 ztunnel。 ztunnel 取得到 FD 之後就可以在 Pod 的網路空間中建立套接字。

 

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協議

 

以下是一個簡化的 HBONE CONNECT 請求範例，利用 x-envoy-original-dst-host、x-istio-auth-userinfo 等頭資訊來傳遞路由和身分認證所需的內容。

 

在這個範例裡，假設 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）

跨節點的加密流量（L4）

 

跨節點的加密流量（L7）

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

 

• 來源 ztunnel 先把流量隧道給 Waypoint；

 

• Waypoint 在 HTTP 層做鑑權、路由等；

 

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

 

• 目標 ztunnel 解封裝後給目標 Pod。

 

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

 

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

對於非 Istio網格內部的流量，透過 Pod IP和連接埠直接存取 Pod時，為了防止這些流量逃脫 ztunnel的掌控，也需要攔截這些流量。如果流量是存取的應用程式端口，透過判斷資料包上是否帶有 0x539 標記，如果沒有，則將其轉送到 ztunnel 監聽的 15006 明文端口，經 ztunnel 處理後會帶上 0x539 標記，然後就可以存取應用程式的目標端口了；如果流量的目的是 15008，那麼就可以判斷到應用程式的目標端口了；如果流量的目的是 150087

 

對於大部分只需 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 流量為主，對資源和管理要求高的團隊可以專注。