Istio 引入 Ambient Mesh(無 sidecar 數據平面模式),讓服務網格真正成爲通信基礎設施

原文:https://makeoptim.com/service-mesh/istio-introducing-ambient-mesh

前言

Istio 於 2022 年 9 月 7 日宣佈引入一種無 sidecar 數據平面模式(Ambient Mesh)

Ambient Mesh 將數據面的代理從應用 pod 中剝離出來獨立部署,以徹底解決服務網格基礎設施和應用部署耦合的問題

Ambient Mesh

今天,我們很高興地介紹 “Ambient Mesh”,這是 Istio 提供的一種新的數據平面模式,旨在簡化操作,提供更廣泛的應用兼容性,並降低基礎設施的成本。Ambient Mesh 使得用戶可以選擇使用一種可以集成到其基礎設施中的 Mesh 數據平面,而不是需要和應用一起部署的 sidecar。同時,該模式可以提供和 Sidecar 模式相同的零信任安全、遙測和流量管理等 Istio 的核心功能。目前 Ambient Mesh 已提供了預覽版,我們正努力爭取在未來幾個月內將其推向生產就緒。

Istio 和 Sidecar

自誕生以來,Istio 架構的一個關鍵特徵就是使用 Sidecar – 與應用容器一起部署的可編程代理。sidecar 模式可以讓應用程序在不對代碼進行重大修改的前提下獲得 Istio 提供的各種好處(流量治理,應用安全,可觀察性等)。

Istio 的傳統模式將 Envoy 代理作爲 sidecar 部署在應用 pod 中

雖然相對於重構應用程序而言,sidecar 模式有很大的優勢,但這種模式並沒有在應用程序和 Istio 數據平面之間提供完美的隔離。這導致了下述這些限制:

  • 侵入性 - 必須通過修改應用程序的 Kubernetes pod spec 來將 sidecar 代理 “注入” 到應用程序中,並且需要將 pod 中應用的流量重定向到 sidecar。因此安裝或升級 sidecar 需要重新啓動應用 pod,這對工作負載來說可能是破壞性的。
  • 資源利用不足 - 由於每個 sidecar 代理只用於其 pod 中相關的工作負載,因此必須針對每個 pod 可能的最壞情況保守地配置 sidecar 的 CPU 和內存資源。這導致了大量的資源預留,可能導致整個集羣的資源利用不足。
  • 流量中斷 - 流量捕獲和 HTTP 處理 通常由 sidecar 完成,這些操作的計算成本很高,並且可能會破壞一些實現和 HTTP 協議不完全兼容的應用程序。

雖然 sidecar 模式依然有它的用武之地 - 後面我們對此會有更多的討論 - 但我們認爲需要有一個侵入性更低、更容易使用的選擇,該選擇將更適合許多服務網格用戶。

分層處理(四層和七層)

在之前的模式中,Istio 在單一的架構組件 sidecar 中實現了從基本的加密到高級的 L7 策略的所有數據平面功能。在實踐中,這使得 sidecar 成爲一個要麼全選要麼沒有的功能組件。即使工作負載只需要簡單的傳輸安全,管理員仍然需要付出部署和維護 sidecar 的運營成本。sidecar 對每個工作負載都有固定的運維成本,無法根據用例的複雜性的不同進行伸縮

Ambient Mesh 採取了一種不同的方法。它將 Istio 的功能分成兩個不同的層次。在底層,有一個安全覆蓋層來處理流量的路由和零信任安全。在這之上,當需要時,用戶可以通過啓用 L7 處理來獲得 Istio 的全部能力。L7 處理模式雖然比安全覆蓋層更重,但仍然作爲基礎設施的一個 ambient 組件運行,不需要對應用 pod 進行修改。

Ambient Mesh 的分層

這種分層的方法允許用戶以增量的方式應用 Istio從完全沒有 mesh,到安全覆蓋,再到完整的 L7 處理,用戶可以根據需要以 namespace 爲操作單位進行平滑過渡。此外,ambient 模式和 sidecar 模式下運行的工作負載可以無縫地進行交互,允許用戶根據隨着時間變化的需求而混合使用不同模式並進行演進。

構建一個 Ambient Mesh

Ambient Mesh 使用了一個共享代理,該共享代理運行在 Kubernetes 集羣的每個節點上。這個代理是一個零信任隧道(簡稱爲 ztunnel),其主要職責是安全地連接和認證 mesh 內的工作負載。節點上的網絡棧會將工作負載的所有流量重定向到本地的 ztunnel 代理。這將 Istio 的數據平面與應用程序的關注點完全分開,可以讓運維在不影響應用的情況下啓用、禁用、伸縮和升級數據平面ztunnel 不對工作負載流量進行 L7 處理,因此相對 sidecar 更爲精簡。大幅降低的複雜性和相關的資源成本使得 Ambient Mesh 適合作爲共享基礎設施進行交付。

Ztunnel 實現了一個服務網格的核心功能:零信任。當爲一個 namespace 啓用 ambient 時,Istio 會創建一個安全覆蓋層(secure overlay),該安全覆蓋層爲工作負載提供 mTLS, 遙測和認證,以及 L4 權限控制,並不需要中斷 HTTP 鏈接或者解析 HTTP 數據。

Ambient Mesh 使用一個節點上的共享 ztunnel 來提供一個零信任的安全覆蓋層

在啓用 Ambient Mesh 並創建安全覆蓋層後,一個 namepace 也可以配置使用 L7 的相關特性。這樣可以在一個 namespae 中提供完整的 Istio 功能,包括 Virtual Service APIL7 遙測L7 授權策略。以這種模式運行的 namespace 使用一個或多個基於 Envoy 的 “waypoint proxy”(waypoint:路徑上的一個點) 來爲工作負載進行 L7 處理。Istio 控制平面會配置集羣中的 ztunnel,將所有需要進行 L7 處理的流量發送到 waypoint proxy。重要的是,從 Kubernetes 的角度來看,waypoint proxy 只是普通的 pod,可以像其他 Kubernetes 工作負載一樣進行自動伸縮。由於 waypoint proxy 可以根據其服務的 namespace 的實時流量需求進行自動伸縮,而不是按照可能的最大工作負載進行配置,我們預計這將爲用戶節省大量資源。

當需要支持更多(七層)特性時,Ambient Mesh 會部署 waypoint proxy,並把 ztunnel 連接到 waypoint proxy 以爲流量應用(七層)策略

Ambient Mesh 使用 HTTP CONNECT over mTLS 來實現其安全隧道,並在流量路徑中插入 waypoint proxy,我們把這種模式稱爲 HBONE(HTTP-Based Overlay Network Environment)。HBONE 提供了比 TLS 本身更乾淨的流量封裝,同時實現了與通用負載平衡器基礎設施的互操作性。Ambient Mesh 將默認使用 FIPS 構建,以滿足合規性需求。關於 HBONE 的更多細節,其基於標準的方法,以及 UDP 和其他非 TCP 協議的計劃,將在未來的博客中介紹。

在一個 mesh 中混合部署 sidecar 和 ambient 模式並不會對系統的能力或安全帶來限制。無論用戶選擇何種部署模式,Istio 控制平面都將確保策略的正確執行。Ambient 只是引入了一個具有更好人體工程學和更靈活的選項而已。

爲何不在本地節點上進行 L7 處理?

Ambient Mesh 採用一個部署在本地節點上的共享 ztunnel 代理來處理 mesh 的零信任方面,而 L7 的處理則交給了獨立部署的 waypoint proxy pod。爲何要這麼麻煩地將流量從 ztunnel 轉接到 waypoint proxy,而不是直接在節點上使用一個共享的完整 L7 代理呢?主要有幾個原因:

  • Envoy 本質上並不支持多租戶。因此如果共享 L7 代理,則需要在一個共享代理實例中對來自多個租戶的 L7 流量一起進行復雜的規則處理,我們對這種做法有安全顧慮。通過嚴格限制只在共享代理中進行 L4 處理,我們大大減少了出現漏洞的機率。

  • 與 waypoint proxy 所需的 L7 處理相比,ztunnel 所提供的 mTLS 和 L4 功能需要的 CPU 和內存佔用要小得多。通過將 waypoint proxy 作爲一個共享的 namespace 基本的資源來運行,我們可以根據該 namespace 的需求來對它們進獨立伸縮,其成本不會不公平地分配給不相關的租戶。

  • 通過減少 ztunnel 的作用範圍,我們可以很容易爲 Istio 和 ztunnel 之間的互操作定義一個標準接口,並可以使用其他滿足該標準接口的安全隧道的實現替換 ztunnel。

但是那些額外增加的跳數呢?

在 Ambient Mesh 中,一個 waypoint proxy 與它所服務的工作負載不一定在同一個節點上。看上去這可能是一個性能問題,但我們認爲,該模式中的網絡延遲最終將與 Istio 目前的 sidecar 實現差不多。我們將在專門的性能博文中討論這個話題,但現在我們可以總結出兩點:

  • 事實上,Istio 的大部分網絡延遲並不是來自於網絡(現代的雲供應商擁有極快的網絡),而是來自於實現其複雜的功能特性所需的大量 L7 處理。sidecar 模式中每個連接需要兩個 L7 處理步驟(客戶端和服務器側各一個),而 Ambient Mesh 將這兩個步驟壓縮成了一個。在大多數情況下,我們認爲這種減少的處理成本能夠補償額外的網絡跳數帶來的延遲。

  • 在部署 Mesh 時,用戶往往首先啓用零信任安全,然後再根據需要選擇性地啓用 L7 功能。Ambient Mesh 允許這些用戶在不需要 L7 處理時完全避開其帶來的成本。

資源開銷

總的來說,我們認爲對大多數用戶而言,Ambient Mesh 具有有更少和更可預測的資源需求。ztunnel 有限的功能允許其作爲一個共享資源部署在節點上,這將顯著減少大多數用戶爲每個工作負荷所需的保留資源。此外,由於 waypoint proxy 是普通的 Kubernetes pods,我們可以根據其服務的工作負載的實時流量需求對其進行動態部署和擴展。

另一方面,我們需要根據最壞情況爲每個工作負載的 sidecar proxy 預留內存和 CPU。進行這些計算是很複雜的,很難計算出一個非常準確的數值,所以在實踐中,管理員傾向於爲 sidecar 過度配置。sidecar 的高額資源預留會導致其他工作負載無法被調度,從而導致節點利用率不足。Ambient Mesh 的每節點的 ztunnel 代理的固定開銷較低,其 waypoint proxy 則可以動態伸縮,因此需要的資源預留總體上要少得多,從而使集羣的資源利用效率更高。

安全問題呢?

隨着一個徹底的新架構的出現,自然會有關於安全的問題。這篇關於 ambient 安全的博文對此做了深入的討論,我們這裏總結下面幾點:

sidecar 與其所服務的工作負載部署在一起,因此任意一方的漏洞會危及到另一方。在 Ambient Mesh 模式中,即使一個應用程序被攻破,ztunnels 和 waypoint 代理仍然可以對被攻破的應用程序的流量執行嚴格的安全策略。此外,鑑於 Envoy 是一個被世界上最大的網絡運營商使用的久經考驗的成熟軟件,它出現安全漏洞的可能性遠低於與它一起運行的應用程序。

雖然 ztunnel 是一個共享資源,但它只能訪問它所運行的節點上的工作負載的密鑰。因此,它出現安全問題時的影響範圍並不比任何其他依賴每節點密鑰進行加密的 CNI 插件差。另外,考慮到 ztunnel 有限的 L4 攻擊面和 Envoy 的上述安全特性,我們覺得這種風險是有限和可以接受的。

最後,雖然 waypoint proxy 是一種共享資源,但它們只限於爲一個 service account 服務。因此它們並不會比現在的 sidecar 模式更差:如果一個 waypoint proxy 被攻破,只會丟失該 waypoint proxy 相關的安全信息,並不會影響其他 service account。

這就是 sidecar 模式的結束嗎?

絕對不是。雖然我們認爲 Ambient Mesh 將是許多網格用戶未來的最佳選擇,但對於那些需要專用數據平面資源的場景,例如合規要求或性能調優,sidecar 仍然是一個不錯的選擇。Istio 將繼續支持 sidecar,而且重要的是,Istio 支持 sidecar 與 Ambient Mesh 無縫互通。事實上,我們今天發佈的 Ambient Mesh 代碼已經支持與基於 sidecar 的 Istio 進行互操作。

瞭解更多

請看一個簡短的視頻,Christian 運行了 Istio Ambient Mesh 的相關組件,並演示 Ambient Mesh 的一些功能。

https://www.youtube.com/embed/nupRBh9Iypo

參與進來

我們今天發佈的是 Istio Ambient Mesh 的早期版本,目前 Ambient Mesh 仍處於活躍的開發之中。我們很高興能在更廣泛的社區進行分享,並期待有更多人蔘與 ambien mesh 的相關工作,以幫助其在 2023 年進入生產就緒。

我們期待通過你的反饋來幫助建造 Ambient Mesh 這個解決方案。你可以在 Istio 實驗版中下載和試用 Ambient Mesh。在 README 中有一份目前缺失的功能和工作項目的清單。請嘗試使用 Ambient Mesh,並告知我們你的想法!

小結

Ambient Mesh 是 Istio 自誕生以來的第二次大的架構變動,從這裏可以看出,Istio 團隊在持續創新,以解決服務網格在生產中面臨的實際問題,讓我們一起期待下一個版本吧。

延伸閱讀

參考

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章