無 Sidecar 又成爲新的趨勢了？

Istio 的實驗性環境網格（Ambient Mesh）號稱能大大降低運營複雜性，但 Linkerd 的擁護者們則認爲 Sidecar 本身並不是問題的關鍵。

一種新的 Istio 服務網格架構拋棄了 Sidecar 代理，憑藉顯著降低運營複雜性的承諾引得企業 IT 專業人士紛紛側目。但競爭對手 Linkerd 項目的支持者則認爲，導致複雜性難題的核心並不是 Sidecar 架構——而是 Envoy 代理。

分佈式應用程序環境中的服務網格網絡方法最早出現在 2016 年，源自專爲虛擬機環境設計的 Linkerd 1.0 版本。由谷歌、IBM 和 Lyft 支持的 Istio 則於 2017 年發佈，主要面向的是 Kubernetes 容器編排環境。Linkerd 2.0 緊隨其後發佈，也開始重點關注 Kubernetes。從那時起，容器編排器的日益普及擴大了服務網格的應用範圍，着力將應用層和開發者從複雜的微服務網絡負擔當中解放出來。

直到今年，這些服務網格的基本架構設計都是相同的——兩者都使用一種稱爲 Sidecar 代理的特殊容器來將網絡管理從應用程序當中剝離出來。這些 Sidecar 代理與應用程序密切相關，作爲各個 Kubernetes Pod 的組成部分。與傳統網絡相比，這種緊密性也讓我們能對應用程序路由和監控進行更細粒度的控制。

但隨着服務網格在大規模環境中得到廣泛應用，Sidecar 代理的侷限性也凸顯了出來。在對性能高度敏感的環境中，將容器綁定到每個應用程序可能會產生難以承受的開銷。因爲期間需要重新啓動所有 Sidecar，這會使服務網格的升級困難重重，可能嚴重影響應用程序的可用性。

應用程序容器也可能與 Sidecar 容器不同步，這會產生更多潛在的可靠性問題。在應用程序可能需要服務網格的某些功能的環境中，管理龐大的 Sidecar 可能產生難以承受的負擔。以雙向 TLS 認證（簡稱 mTLS）爲例，這些功能發生在開放系統互連模型的較低層——特別是 L4 層——但並不需要 L7 層上的完整應用級精細過濾。

Istio Ambient Mesh 項目目前處於實驗性階段，由 Google 和 Solo.io 的工程師在今年 9 月份開源。其中包含了一個新的架構，維護人員稱它通過服務網格 Sidecar 迴避了這些問題。

Ambient Mesh 不會將服務網格的所有功能捆綁到隨每個應用程序一起部署的 Sidecar 中，而是將代理分解爲一組兩個共享資源，稱爲 DaemonSet，分別部署在每個 Kubernetes 集羣上。IT 管理員可以使用相同類型的現有 Istio 配置文件和 Kubernetes 應用程序文件，來指示應用程序是否需要 L4 層或 L7 層路由功能。Ambient Mesh 中的整合代理將據此執行流量路由，而不需要爲每個 Pod 配備一個 Sidecar。

這種新方法纔剛剛起步，但已經有一些 Istio 用戶表示很想一探究竟。

“這太棒了，我們將盡快採用，”Constant Contact 公司首席軟件工程師 David Ortiz 在本週的一次在線採訪中說。“它大大簡化了 Istio 的操作，特別是在升級方面。”

一位 KubeCon 與會者表示，他計劃在 Ambient Mesh 成熟時對其進行仔細評估，並表達了濃厚的興趣。

有線電視提供商 Comcast 雲服務執行總監 Greg Otto 本週在接受採訪時說：“Sidecar 確實發揮過重要的作用，但我們也很希望能以不同的思路服務和擴展 L7 層和 L4 層。在邊緣場景中，我們非常關注 L7 層 [過濾]，但並不想因此影響到整個[網絡]，單獨交給 L4 層[路由] 明顯更適合。”

Otto 說，雖然 Sidecar 代理出於安全目的提供了最嚴格的服務分離，但 Istio 的 Envoy 代理中的大多數關鍵常見漏洞披露（CVE）都源自 L7 層。

“在不需要 [L7 層過濾] 的地方，最好能先把它放一放，”他說。“這樣即使存在 CVE，我們的攻擊面也會小得多。”

Linkerd 主動對線：問題不在於 Sidecar，而在於 Envoy

根據 Linkerd 締造者兼 Buoyant.io 首席執行官 William Morgan 的說法，還有另一種方法可以減少 L7 層的關鍵漏洞以及與 Sidecar 相關的大部分資源開銷：直接棄用 Envoy。

“歸根結底，Sidecar 實際上非常簡單——它們在操作上非常簡單，不難理解，而且故障和安全域非常清楚，”Morgan 說。“問題不在於 Sidecar——而是由於 Enovy 的存在，我們不得不面對一個巨大、多用途、資源匱乏且難以操作的代理。”

過去，對 Envoy 的支持是 Istio 相對於 Linkerd 的一個獨特賣點，這也使其成爲廣受歡迎的雲原生計算基金會畢業項目。但由 Morgan 領導的 Linkerd 維護者則堅持使用他們自己的代理，該代理專爲服務網格而設計，代碼庫規模和資源需求都比 Envoy 更小。

因此，一位企業 Linkerd 用戶表示，他認爲問題的關鍵不是打造出無 Sidecar 服務網格，畢竟 Sidecar 本身跟簡單和透明並不矛盾。

丹麥數字金融服務公司 Lunar 首席平臺架構師 Kasper Nissen 本週接受採訪時表示：“從我們的角度來看，Sidecar 既簡單又易於理解——它與我們使用的其他容器技術沒什麼區別。一年半前，我們默認使用全服務網格，相應的資源消耗可能也就增加了 10%。跟我們獲得的 mTLS 和詳盡可見性效果相比，這並不算多。”

Nissen 說，他也遇到過 Sidecar 代理和 Lunar 使用的 Humio 日誌分析應用程序間不同步的問題。如果 Sidecar 重新啓動，該服務沒有時間轉移其本地數據，於是 Nissen 團隊只能 “設置超時、聽天由命”，坐視部分數據因此丟失。

然而，Morgan 和 Nissen 堅持認爲，Sidecar 同步問題的根源在於 Kubernetes 網絡的一個更深層次的問題，這個問題在開源社區三年來一直沒有解決。默認情況下，沒有辦法確保各種容器（無論是由 Linkerd 等服務使用的短期 init 容器還是常規應用程序容器）按特定順序啓動和停止。2019 年曾有一項 Kubernetes 增強提案嘗試解決這個問題，但被拒絕了；社區中的討論仍在繼續，但情況並沒有改變。

“如今一切服務都在作爲 Sidecare 進行交付，所以這個問題應該由 Kubernetes 方面負責解決。”Nissen 說。

Morgan 也認爲，在 Kubernetes 中解決這個問題纔是根治 Sidecar 同步性挑戰的最佳方法。

“雲原生世界向來以探索新功能（而非修復舊設計）爲先，所以大家對這類提議的興趣相對不大。但 Sidecar 將繼續成爲服務網格的未來，”Morgan 說。“我們當然知道 Sidecar 有缺陷，可正確答案應該是最終通過 Kubernetes 的調整來解決，而不是大幅改變架構、向基礎設施操作中引入更復雜的機制。”

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/5uvn7E7LP11CgPKWbfZ8ow