介紹 Ambient Mesh

今天，我們很高興推出「ambient mesh」及其參考實作：一種新的 Istio 資料平面模式，旨在簡化操作、更廣泛的應用程式相容性並降低基礎設施成本。Ambient mesh 讓使用者可以選擇放棄 Sidecar 代理，而改用整合到其基礎設施中的資料平面，同時保持 Istio 零信任安全、遙測和流量管理的核心功能。我們正在與 Istio 社群分享 ambient mesh 的預覽版，我們正在努力在未來幾個月內使其達到生產就緒狀態。

Istio 和 Sidecar

自成立以來，Istio 架構的一個決定性特徵是使用 Sidecar – 與應用程式容器一起部署的可程式化代理。Sidecar 允許操作員獲得 Istio 的優勢，而無需應用程式進行重大改造及其相關成本。

儘管 Sidecar 比重構應用程式具有顯著優勢，但它們並不能在應用程式和 Istio 資料平面之間提供完美的隔離。這導致了一些限制

• 侵入性 - Sidecar 必須透過修改它們的 Kubernetes Pod 規格並在 Pod 內重新導向流量來「注入」到應用程式中。因此，安裝或升級 Sidecar 需要重新啟動應用程式 Pod，這可能會對工作負載造成干擾。
• 資源利用不足 - 由於 Sidecar 代理專用於其相關的工作負載，因此必須為每個單獨 Pod 的最壞情況使用配置 CPU 和記憶體資源。這會增加大量的保留，導致整個叢集資源利用不足。
• 流量中斷 - 流量捕獲和 HTTP 處理（通常由 Istio 的 Sidecar 完成）計算量很大，並且可能會中斷某些具有不符合標準的 HTTP 實作的應用程式。

雖然 Sidecar 有其用武之地（稍後將詳細介紹），但我們認為需要一種侵入性較小且更簡單的選項，這將更適合許多服務網格使用者。

切割層

傳統上，Istio 在單個架構元件（Sidecar）中實作所有資料平面功能，從基本加密到進階 L7 策略。實際上，這使得 Sidecar 成為一種全有或全無的方案。即使工作負載只需要簡單的傳輸安全性，管理員仍然需要支付部署和維護 Sidecar 的操作成本。Sidecar 每個工作負載都有固定的操作成本，不會根據用例的複雜性而擴展。

Ambient 資料平面採用不同的方法。它將 Istio 的功能分為兩個不同的層。在基礎層，有一個安全覆蓋層，負責處理流量的路由和零信任安全性。在此之上，在需要時，使用者可以啟用 L7 處理以存取 Istio 的全部功能。L7 處理模式雖然比安全覆蓋層更重，但仍作為基礎設施的 Ambient 元件執行，無需修改應用程式 Pod。

這種分層方法允許使用者以更漸進的方式採用 Istio，根據需要，在每個命名空間的基礎上，從沒有網格平穩過渡到安全覆蓋層，再到完整的 L7 處理。此外，在不同 Ambient 層或使用 Sidecar 執行的工作負載可以無縫互操作，允許使用者根據隨時間變化的特定需求混合和匹配功能。

建構 Ambient Mesh

Istio 的 Ambient 資料平面模式使用在 Kubernetes 叢集中每個節點上執行的共享代理。這個代理是一個零信任通道（或 ztunnel），其主要職責是安全地連線和驗證網格內的元素。節點上的網路堆疊會將參與工作負載的所有流量重新導向到本機 ztunnel 代理。這完全將 Istio 資料平面的關注點與應用程式的關注點分開，最終允許操作員啟用、停用、擴展和升級資料平面，而不會干擾應用程式。ztunnel 不對工作負載流量執行 L7 處理，使其比 Sidecar 精簡得多。這種複雜性的巨大降低和相關的資源成本使其適合作為共享基礎設施交付。

Ztunnel 啟用服務網格的核心功能：零信任。當命名空間啟用 Ambient 模式時，會建立一個安全覆蓋層。它為工作負載提供 mTLS、遙測、驗證和 L4 授權，而無需終止或剖析 HTTP。

啟用 Ambient 模式並建立安全覆蓋層後，可以將命名空間設定為使用 L7 功能。這允許命名空間實作 Istio 的全部功能，包括 Virtual Service API、L7 遙測和 L7 授權策略。在此模式下運作的命名空間使用一個或多個基於 Envoy 的 航點代理 來處理該命名空間中工作負載的 L7 處理。Istio 的控制平面會設定叢集中的 ztunnel，以將所有需要 L7 處理的流量傳遞到航點代理。重要的是，從 Kubernetes 的角度來看，航點代理只是可以像任何其他 Kubernetes 部署一樣自動擴展的常規 Pod。我們預期這會為使用者節省大量資源，因為航點代理可以自動擴展以滿足其服務命名空間的即時流量需求，而不是操作員預期的最大最壞情況負載。

Ambient mesh 使用 mTLS 上的 HTTP CONNECT 來實作其安全通道並在路徑中插入航點代理，我們將這種模式稱為 HBONE (HTTP-Based Overlay Network Environment)。HBONE 提供比單獨使用 TLS 更乾淨的流量封裝，同時實現與通用負載平衡器基礎設施的互通性。預設情況下使用 FIPS 建置來滿足合規性需求。有關 HBONE、其基於標準的方法以及 UDP 和其他非 TCP 協定的計劃的更多詳細資訊將在未來的部落格中提供。

在單個網格中混合使用 Sidecar 和 Ambient 模式不會對系統的功能或安全屬性造成限制。無論選擇哪種部署模型，Istio 控制平面都能確保正確強制執行策略。Ambient 模式只是引入了一個具有更好人體工學和更高靈活性的選項。

為什麼不在本機節點上進行 L7 處理？

Ambient 模式使用節點上共享的 ztunnel 代理來處理網格的零信任方面，而 L7 處理則在單獨排程的 Pod 中的航點代理中進行。為什麼要費心進行間接處理，而不僅僅是在節點上使用共享的完整 L7 代理？有幾個原因

• Envoy 本質上不是多租戶的。因此，我們擔心在共享實例中混合來自多個不受約束的租戶的 L7 流量的複雜處理規則存在安全問題。透過嚴格限制為 L4 處理，我們可以顯著減少漏洞暴露面。
• 與航點代理中所需的 L7 處理相比，ztunnel 提供的 mTLS 和 L4 功能需要小得多的 CPU 和記憶體佔用空間。透過將航點代理作為共享的命名空間資源執行，我們可以根據該命名空間的需求獨立擴展它們，並且其成本不會在不相關的租戶之間不公平地分配。
• 透過縮小 ztunnel 的範圍，我們允許它被其他可以滿足明確定義的互通性契約的安全通道實作所取代。

但是那些額外的躍點呢？

使用 Ambient 模式，航點不一定保證與其服務的工作負載位於同一節點上。雖然乍看之下這似乎是一個效能問題，但我們相信延遲最終會與 Istio 目前的 Sidecar 實作一致。我們將在專門的效能部落格文章中進行更多討論，但現在我們將用兩點來總結

• 實際上，Istio 的大部分網路延遲並非來自網路 (現代雲端提供者擁有極快的網路)。相反，最大的罪魁禍首是 Istio 實作其複雜功能集所需的密集 L7 處理。與 Sidecar 為每個連線實作兩個 L7 處理步驟（每個 Sidecar 一個）不同，Ambient 模式將這兩個步驟合併為一個。在大多數情況下，我們預期這種降低的處理成本可以彌補額外的網路躍點。
• 使用者通常會部署網格以啟用零信任安全態勢作為第一步，然後根據需要選擇性地啟用 L7 功能。Ambient 模式允許這些使用者在不需要時完全繞過 L7 處理的成本。

資源開銷

總體而言，我們預期 Istio 的 Ambient 模式對大多數使用者而言具有更少且更可預測的資源需求。ztunnel 的有限責任允許它作為節點上的共享資源部署。這將大大減少大多數使用者所需的每個工作負載保留。此外，由於航點代理是普通的 Kubernetes Pod，它們可以根據其服務的工作負載的即時流量需求動態部署和擴展。

另一方面，Sidecar 需要為每個工作負載保留最差情況下的記憶體和 CPU。進行這些計算很複雜，因此實際上管理員傾向於過度配置。這導致節點利用率不足，因為高保留量會阻止其他工作負載被排程。Ambient 模式較低的每個節點固定開銷和動態擴展的航點代理，將需要在總體上更少的資源保留，從而更有效率地使用叢集。

那麼安全性呢？

隨著一個全新的架構出現，自然會產生關於安全性的問題。關於環境模式安全性的部落格有深入的探討，但我們將在此處進行總結。

Sidecar 與它們所服務的工作負載共置，因此，一方的漏洞會危害到另一方。在環境網格模型中，即使應用程式遭到入侵，ztunnel 和航點代理仍然可以對遭到入侵的應用程式流量強制執行嚴格的安全策略。此外，考慮到 Envoy 是全球最大網路營運商使用的成熟且久經考驗的軟體，它可能比與其並行的應用程式更不容易受到攻擊。

雖然 ztunnel 是一個共享資源，但它只能存取目前在其執行節點上的工作負載的金鑰。因此，它的影響範圍不比任何其他依賴於每個節點金鑰進行加密的加密 CNI 更糟。此外，考慮到 ztunnel 有限的 L4 攻擊面和 Envoy 前述的安全特性，我們認為這種風險是有限且可接受的。

最後，雖然航點代理是共享資源，但它們僅限於服務一個服務帳戶。這使得它們不比現在的 Sidecar 更糟；如果一個航點代理遭到入侵，與該航點關聯的憑證會遺失，其他任何東西都不會遺失。

這是 Sidecar 的末路嗎？

絕對不是。雖然我們相信環境網格將成為未來許多網格使用者的最佳選擇，但 Sidecar 對於那些需要專用資料平面資源（例如，用於合規性或效能調優）的使用者來說仍然是一個不錯的選擇。Istio 將繼續支援 Sidecar，並且重要的是，允許它們與環境模式無縫互通。事實上，我們今天發布的環境模式程式碼已經支援與基於 Sidecar 的 Istio 互通。

了解更多

觀看一段簡短影片，了解 Christian 如何介紹 Istio 環境模式元件，並示範一些功能

參與貢獻

我們今天發布的是 Istio 中環境模式的早期版本，它仍然處於積極開發中。我們很高興與更廣泛的社群分享它，並期待更多人參與其中，在我們邁向 2023 年的生產就緒階段時，共同塑造它。

我們非常希望收到您的回饋，以幫助塑造這個解決方案。支援環境模式的 Istio 版本可於 下載和試用，位於 Istio 實驗性儲存庫。遺失的功能和工作項目的清單可在 README 中找到。請試用一下，並告訴我們您的想法！

感謝為啟動環境網格做出貢獻的團隊！

• Google：Craig Box、John Howard、Ethan J. Jackson、Abhi Joglekar、Steven Landow、Oliver Liu、Justin Pettit、Doug Reid、Louis Ryan、Kuat Yessenov、Francis Zhou
• Solo.io：Aaron Birkland、Kevin Dorosh、Greg Hanson、Daniel Hawton、Denis Jannot、Yuval Kohavi、Idit Levine、Yossi Mesika、Neeraj Poddar、Nina Polshakova、Christian Posta、Lin Sun、Eitan Yarmush