文｜田陽 （花名：烈元）
MOSN Maintainer
專注雲原生等技術領域
本文3042字 閱讀 10 分鐘
1. 背景
Service Mesh 被越來越多的公司認可並實踐，在實際落地過程中也遇到了形形色色的問題，同時架構也在持續演進去解決這些問題：有的從初始的 DaemonSet mode 轉變為 Sidecar mode，如 Linkerd ；有的從做 CNI 延伸到 Service Mesh 場景， 結合 eBPF 使用 DaemonSet mode，如 Cilium ；如今 Istio 也新增了 Ambient Mesh ，支援 DaemonSet mode 作為其主推模式。
不難看出一個演進趨勢就是圍繞著是否需要 Sidecar 而展開，那麼 Service Mesh 的下一站將會是 Sidecarless 嗎？本文將對目前的社群趨勢做一個簡要分析， 最後也將介紹螞蟻在這方面的探索和實踐。
2. 社群趨勢
2.1 Cilium
Cilium[1] 是目前最火的雲原生網路技術之一，基於革命性的核心技術 eBPF，提供、保護和觀察容器工作負載之間的網路連線。
在 6 月份，Cilium 釋出了 1.12 版本，其中釋出了 Service Mesh 能力、Sidecarless 架構，它提供了兩種模式：
透過圖表我們可以發現：針對 L3/L4 的能力，Cilium 使用核心的 eBPF 直接支援；對於 L7 的部分能力，將使用 DaemonSet 部署的 Envoy 來支援。Cilium 認為大部分能力都不需要 L7 的參與，透過 eBPF 就能滿足，所以 Cilium 也稱自己為核心級服務網格。
針對於此 Cilium 也有一個解釋，結合應用程式 TCPD 最終被合入 linux kernel 發展為 iptables 為例，認為 Mesh 也應該作為基礎能力下沉到 linux kernel 作為網路的基礎元件，就類似於 TCP，作為 Linux 的一部分透明地提供的服務。
在當需要 L7 代理能力的時候，會構建 DaemonSet Envoy 處理 L7 的能力。Envoy 也已經有了 Namespace 的初步概念，它們被稱為監聽器。監聽器可以攜帶單獨的配置並獨立執行，從而可以支援多租戶的配置隔離 (但目前還做不到資源和故障的隔離） 。
Cilium 認為 DaemonSet 相比 Sidecar 最明顯的好處就是代理數大大減少，減少資源和管理成本。
可以看出 Cilium Service Mesh 的發展歷程是由下而上，從核心層慢慢向業務層擴充套件自己的服務邊界，由 eBPF 來支援服務網路也是有一定的立場因素。但 eBPF 並不是銀彈，DaemonSet mode 也是有一些其他的問題，收益和損失都是相對的。
2.2 Linkerd
當然，Cilium 這個架構也不乏有挑戰者，其中來頭最大的就是 Linkerd[2] （Service Mesh 概念的提出者） 的創始人 William Morgan ，比較有意思的是 Linkerd 最開始的架構是 DaemonSet mode ，在後面的版本才換成 Sidecar mode ，對於此，作為逆行者的他應該最有發言權。
在 William Morgan 的最新文章[3] 中也客觀提出了 eBPF 的一些侷限性，為了保證 eBPF 的安全執行而不影響 kernel ，需要透過驗證器驗證是否有不正確的行為，這就導致 eBPF 的編寫存在一定的潛規則，比如不能有無界迴圈；不能超過預設的大小等，程式碼的複雜性也就受到了一定限制。所以較複雜的邏輯用 eBPF 來實現也是有較高的成本的。
文章中也提到了 DaemonSet 的一些弊端：
- 資源管理不可評估：這取決於 K8s 排程多少 Pod 到該 Node；
- 隔離性：所有應用公用一個 Proxy ，相互影響穩定性；
- 爆炸半徑變大：影響整個 Node 的 Pod 例項；
- 安全問題更復雜：比如 Proxy 儲存有整個 Node 的秘鑰。
簡而言之，Sidecar 模式繼續貫徹了容器級別的隔離保護 —— 核心可以在容器級別執行所有安全保護和公平的多租戶排程。容器的隔離仍然可以完美的執行，而 DaemonSet 模式卻破壞了這一切，重新引入了爭搶式的多租戶隔離問題。
當然他也認為 eBPF 可以更好的促進 Mesh 的發展，eBPF+Sidecar 的結合是 Mesh 的未來。
我們也比較認可他對於 eBPF 的看法， eBPF 就像是一把瑞士軍刀，小巧精湛，作為膠水把各種網路資料面連線起來，提供基礎網路能力，比如提供訪問加速，透明劫持，網路可觀察性等能力。但要開發複雜的業務能力，在實操之後，感覺還是有點力不從心。目前我們團隊也正在使用 eBPF 開發 K8s Service 和透明攔截等基礎網路能力。
William Morgan 的說法看著也不無道理，我們先不急著站隊，再來看看 Istio 是怎麼做的，看是否會有新的想法~
2.3 Istio
在 9 月份，Service Mesh 領域的當家花旦 Istio 毫無徵兆的釋出了 Ambient Mesh ，並作為自己後續的主推架構，簡單來講就是把資料面從 Sidecar 中剝離出來獨立部署，Sidecarless 架構，以徹底解決 Mesh 基礎設施和應用部署耦合的問題。
比較好奇 Istio 在沒有經過社群討論和落地案例的情況下，是怎樣決策篤定這個新的架構方向的呢？
Istio 認為 Sidecar mode 存在如下三個問題：
- 侵入性
必須透過修改應用程式的 Kubernetes pod spec 來將 Sidecar 代理 “注入” 到應用程式中，並且需要將 Pod 中應用的流量重定向到 Sidecar 。因此安裝或升級 Sidecar 需要重新啟動應用 Pod ，這對工作負載來說可能是破壞性的。
- 資源利用不足
由於每個 Sidecar 代理只用於其 Pod 中相關的工作負載，因此必須針對每個 Pod 可能的最壞情況保守地配置 Sidecar 的 CPU 和記憶體資源。這導致了大量的資源預留，可能導致整個叢集的資源利用不足。
- 流量中斷
流量捕獲和 HTTP 處理 通常由 Sidecar 完成，這些操作的計算成本很高，並且可能會破壞一些實現和 HTTP 協議不完全相容的應用程式。
Envoy 的創始人也來湊了個熱鬧，他對 Sidecar 架構也是頗有微詞。
我們在落地過程中也是遇到了類似的痛點，比如隨著機房規模和應用規模的變大，應用的連線數繼續膨脹導致 CPU 和 MEM 資源佔用也在持續增加，但這一切都不是應用本身想去關心的。
那麼讓我們來解開 Ambient Mesh 架構真面目，是怎樣來解決 Sidecar mode 的問題， 架構主要提出了分層：
從圖中可以看出，跟 Cilium 有一些類似，這兒的兩層資料面都是基於 Envoy 來構建的，Secure Overlay Layer 主要處理 L4 場景，DaemonSet 部署，L7 processing Layer 主要處理 L7 場景，以 gateway 形式透過 Pod 部署，一個應用部署一個 gateway。
圖中的 ztunnel 就是 L4 （DaemonSet 部署） ，waypoint 就是 L7 （Pod 部署） ，L4 和 L7 都是可選的，可以根據業務場景靈活組合，比如沒有 L7 的場景，直接就用 L4 即可。
注：圖中的 ztunnel 就是L4 （DaemonSet 部署） ，waypoint 就是 L7 （Pod 部署） 。
無形之中，Ambient Mesh 架構對 William Morgan 評論中的問題也做了一定的解決和反駁：
- 資源評估
Istio 認為 L4 資源佔用少，然後 L7 的資源佔用是透過 Pod 部署，可以更好的彈性。
- 隔離性
每個應用都將有一個 L7 叢集，相互不影響。
- 爆炸半徑
L4 邏輯簡單相對比較穩定，L7 獨立部署，也隻影響自身應用。
- 安全問題
Istio 認為 Envoy 作為被世界上最大的網路運營商使用的久經考驗的成熟軟體，它出現安全漏洞的可能性遠低於與它一起執行的應用程式。DaemonSet 模式下，出現安全問題時的影響範圍並不比任何其他依賴每節點金鑰進行加密的 CNI 外掛差。有限的 L4 攻擊面和 Envoy 的安全特性，Istio 覺得這種風險是有限和可以接受的。
針對 William Morgan 提到的 DaemonSet 增加了安全風險，我們也持保留意見，就拿證書場景為例，在沒有統一接入層 （南北向接入閘道器） 這個產品之前 （15 年前，還沒有 K8s ） ，應用的 HTTPS 證書和私鑰都是放在跟應用一起部署的 Tengine 上，就類似於 Sidecar 模式，但接入層誕生的一個原因恰恰就是為了集中管理證書和私鑰來減少安全風險，透過證書和私鑰的分離架構，私鑰單獨存放在更加安全的 key 叢集，並且透過 QAT 硬體加速，HTTPS 效能也更加高效。
把 HTTPS 和 L7 服務治理能力從應用空間解耦出來下沉為基礎設施，也讓我們有更多的機會去做集中的最佳化和演進，同時也對應用更加透明，那個時代的以應用為中心。
統一接入層和目前 Service Mesh 的 DaemonSet mode 有著不少相似之處，DaemonSet mode 也可以認為是一個東西流量的 Node 接入層。
網路通訊作為基礎設施，和應用完全解耦後，可以更好的最佳化和演進，也能更加透明高效的為應用提供相關基礎能力，比如網路連線治理，可信身份，鏈路加密，流量映象，安全隔離，服務治理等，更好的以應用為中心。
從 Cilium 到 Linkerd，再到 Istio，幾大社群相互切磋，歸根結底還是大家的業務場景不一樣，也或者是立場不一樣。在安全性，穩定性，管理成本，資源佔用上，總是會有一個側重點，這是需要根據不同的業務場景去選擇，脫離業務場景談架構，還是比較空洞。
3. 下一站
沒有最好的架構，只有最適合自己的架構，在大家的業務場景，你會選擇 Sidecar ，還是 Sidecarless ，你認為的下一站是什麼呢？
下週我們即將釋出 《降本增效: 螞蟻在 Sidecarless 的探索和實踐》，一起來聊聊螞蟻在這個方向的探索和演進，期待和大家的交流~
4. 引用
[1]Cilium :
https://istio.io/latest/blog/2022/introducing-ambient-mesh/
[2]Linkerd :
https://isovalent.com/blog/post/cilium-service-mesh/
[3]William Morgan 的最新文章:
https://buoyant.io/blog/ebpf-sidecars-and-the-future-of-the-service-mesh
MOSN Star 一下✨：
本週推薦閱讀
[順豐科技 Service Mesh：落地半年，最初目標已經實現，將在更多場景進行大規模探索
](http://mp.weixin.qq.com/s?__b...)