深入探討 Ambient 與 Sidecar 共存時的網路流量路徑
深入探討 Ambient 與 Sidecar 共存時的流量路徑。
Istio 有兩種部署模式：Ambient 模式和 Sidecar 模式。前者仍在開發中，後者是經典模式。因此，Ambient 模式和 Sidecar 模式的共存應是一種常規的部署形式，這也是為什麼這篇部落格可能對 Istio 使用者有所幫助的原因。
背景
在現代微服務架構中，服務之間的通訊和管理至關重要。為了應對這個挑戰，Istio 作為一種服務網格技術應運而生。它透過利用 Sidecar 提供流量控制、安全性和卓越的觀察能力。為了進一步提高 Istio 的適應性和靈活性，Istio 社群開始探索一種新模式 - Ambient 模式。在此模式下，Istio 不再依賴顯式的 Sidecar 注入，而是透過 ztunnel 和航點代理實現服務之間的通訊和網格管理。Ambient 也帶來了一系列改進，例如更低的資源消耗、更簡單的部署以及更靈活的配置選項。啟用 Ambient 模式後，我們不再需要重新啟動 Pod，這使得 Istio 可以在各種場景中發揮更好的作用。
有很多部落格（可以在這篇部落格的參考資源部分找到）介紹和分析了 Ambient，而這篇部落格將分析 Istio Ambient 和 Sidecar 模式下的網路流量路徑。
為了闡明網路流量路徑並使其更容易理解，這篇部落格文章將探討以下兩種場景，並附上相應的圖表：
- Ambient 模式服務到 Sidecar 模式服務的網路路徑
- Sidecar 模式服務到 Ambient 模式服務的網路路徑
關於分析的資訊
此分析基於 Istio 1.18.2，其中 Ambient 模式使用 iptables 進行重新導向。
Ambient 模式 sleep 到 Sidecar 模式 httpbin
第一個場景的部署和配置
sleep部署在命名空間 foo 中sleepPod 被排程到節點 A
httpbin部署在命名空間 bar 中httpbin被排程到節點 B
- foo 命名空間啟用 Ambient 模式（foo 命名空間包含標籤：
istio.io/dataplane-mode=ambient） - bar 命名空間啟用 Sidecar 注入（bar 命名空間包含標籤：
istio-injection: enabled）
根據以上描述，部署和網路流量路徑如下：
如果啟用了 Ambient 模式，ztunnel 將以 DaemonSet 的形式部署在 istio-system 命名空間中，而 istio-cni 和 ztunnel 將為每個節點上的 ztunnel Pod 和 Pod 生成 iptables 規則和路由。
所有進出啟用 Ambient 模式的 Pod 的網路流量都將基於網路重新導向邏輯通過 ztunnel。然後，ztunnel 將流量轉發到正確的端點。
Ambient 模式 sleep 到 Sidecar 模式 httpbin 的網路流量路徑分析
根據上面的圖表，網路流量路徑的詳細資訊如下所示：
(1) (2) (3) sleep 服務的請求流量從 sleep Pod 的 veth 發出，根據 iptables 規則和路由規則，流量將被標記並轉發到節點中的 istioout 裝置。節點 A 上的 istioout 裝置是一個 Geneve 通道，而通道的另一端是 pistioout，它位於同一節點上的 ztunnel Pod 內。
(4) (5) 當流量通過 pistioout 裝置到達時，Pod 內的 iptables 規則會攔截流量並通過 Pod 中的 eth0 介面重新導向到埠 15001。
(6) 根據原始請求資訊，ztunnel 可以取得目標服務的端點清單。然後，它將處理將請求傳送到端點，例如其中一個 httpbin Pod。最後，請求流量將通過容器網路進入 httpbin Pod。
(7) 到達 httpbin Pod 的請求流量將被其 iptables 規則攔截，並通過 Sidecar 的埠 15006 重新導向。
(8) Sidecar 會處理通過埠 15006 傳入的入站請求流量，並將流量轉發到同一 Pod 中的 httpbin 容器。
Sidecar 模式 sleep 到 Ambient 模式 httpbin 和 helloworld
第二個場景的部署和配置
sleep部署在命名空間 foo 中sleepPod 被排程到節點 A
httpbin部署在命名空間 bar-1 中httpbinPod 被排程到節點 Bhttpbin的航點代理已停用
helloworld部署在命名空間 bar-2 中helloworldPod 被排程到節點 Dhelloworld的航點代理已啟用- 航點代理被排程到節點 C
- foo 命名空間啟用 Sidecar 注入（foo 命名空間包含標籤：
istio-injection: enabled） - bar-1 命名空間啟用 Ambient 模式（bar-1 命名空間包含標籤：
istio.io/dataplane-mode=ambient）
根據以上描述，部署和網路流量路徑如下：
Sidecar 模式 sleep 到 Ambient 模式 httpbin 的網路流量路徑分析
從 sleep Pod（Sidecar 模式）到 httpbin Pod（Ambient 模式）的請求的網路流量路徑如上圖的上半部分所示。
(1) (2) (3) (4) sleep 容器向 httpbin 發送請求。請求被 iptables 規則攔截並導向到 sleep Pod 中 Sidecar 上的埠 15001。然後，Sidecar 會處理請求，並根據從 istiod（控制平面）收到的配置來路由流量，將流量轉發到節點 B 上與 httpbin Pod 對應的 IP 位址。
(5) (6) 在將請求傳送到裝置對（veth httpbin <-> httpbin Pod 內的 eth0）之後，該請求將被攔截，並使用 iptables 和路由規則轉發到節點 B 上 httpbin Pod 正在執行的 istioin 裝置，並遵循其 iptables 和路由規則。節點 B 上的 istioin 裝置和同一節點上 ztunnel Pod 內的 pistion 裝置通過 Geneve 通道連接。
(7) (8) 在請求進入 ztunnel Pod 的 pistioin 裝置後，ztunnel Pod 中的 iptables 規則會攔截流量，並通過 Pod 內執行的 ztunnel 代理上的埠 15008 重新導向。
(9) 進入埠 15008 的流量將被視為入站請求，然後 ztunnel 將請求轉發到同一節點 B 中的 httpbin Pod。
Sidecar 模式 sleep 通過航點代理到 Ambient 模式 httpbin 的網路流量路徑分析
與圖表的上半部分相比，下半部分在 sleep、ztunnel 和 httpbin Pod 之間的路徑中插入了一個航點代理。Istio 控制平面具有服務網格的所有服務資訊和配置。當部署具有航點代理的 helloworld Pod 時，sleep Pod Sidecar 收到的 helloworld 服務的 EDS 配置將更改為 envoy_internal_address 類型。這會導致通過 Sidecar 的請求流量通過 基於 HTTP 的覆蓋網路 (HBONE) 協議轉發到節點 C 上航點代理的埠 15008。
航點代理是 Envoy 代理的一個實例，並根據從控制平面收到的路由配置將請求轉發到 helloworld Pod。一旦流量到達節點 D 上的 veth，它就會遵循與先前場景相同的路徑。
總結
Sidecar 模式是 Istio 成為出色服務網格的原因。但是，Sidecar 模式也可能會導致問題，因為它要求應用程式和 Sidecar 容器在同一 Pod 中執行。Istio Ambient 模式透過集中式代理（ztunnel 和航點）實現服務之間的通訊。Ambient 模式提供了更高的靈活性和可擴展性，減少了資源消耗，因為它不需要網格中每個 Pod 都有一個 Sidecar，並允許更精確的配置。因此，毫無疑問，Ambient 模式是 Istio 的下一個發展方向。顯然，Sidecar 和 Ambient 模式的共存可能會持續很長時間，儘管 Ambient 模式仍處於 Alpha 階段，而 Sidecar 模式仍然是 Istio 的建議模式，但隨著 Ambient 模式朝著 Beta 和未來版本邁進，它將為使用者提供一個更輕量級的選項，以執行和採用 Istio 服務網格。
參考資源
