服務網格 2022 ：Gateway API 是最大驚喜，eBPF 不會改變遊戲規則

作者 | William Morgan

譯者 | 平川

策劃 | 褚杏娟

本文最初釋出于 Linkerd 官方部落格。

今年對于 Linkerd 是個好年景。盡管軟體行業的大部分都在經濟衰退中苦苦掙紮，但 Linkerd 的應用卻一直在增長。事實上，日志名額顯示，運作 Linkerd 的穩定 Kubernetes 叢集數量在 2022 年翻了一番。Linkerd 可能是唯一一個從 CNCF 畢業的服務網格，但它肯定不會因為畢業而放緩發展的腳步！

這種增長從何而來？為什麼是現在？基于 2022 年與新采用者的交流，我們認為情況是這樣的：由于極端的炒作，再加上炒作最厲害的項目相對并不成熟且比較複雜，服務網格在早期的名聲并不好。早期的采用者決定等到一切塵埃落定時再說。現在，他們回來了，他們看到了第一次的事兒，正渴望着有一種不會讓他們背負衆所周知的操作複雜性的選擇。

自然地，他們轉向了 Linkerd，因為簡單，它成了服務網格領域一個獨特的存在。Linkerd 的主要優勢在于它的資料平面。Linkerd 是唯一一個避開了 Envoy 的服務網格，它把重點放在了專用的邊車（sidecar）“微代理”上。在 2018 年，這是一個有争議的決定；在 2022 年，事實證明這種方法可以帶來巨大的回報。當其他項目花費時間為其資料平面的複雜性和資源消耗建構變通方案時，Linkerd 卻專注于提供強大的功能，如多叢集故障轉移和基于Gateway API的完整L7授權政策。

但 2022 年，也并非完全像我們想象的那樣。這一年裡，即使是我們這些“頭發花白”的老兵也得到了一些教訓，同時也得到了一些真正的驚喜。以下是 2022 年讓我們感到驚喜的幾件事。

驚喜 1：Kubernetes 的 Gateway API 非常适合服務網格

到目前為止，Gateway API 是我們 2022 年最大的驚喜，實際上，它還讓我們中途更改了計劃。年中，當時我們正在最終确定 Linkerd 的 L7 授權功，Gateway API 在 Kubernetes 進入了 Beta 測試。當我們更深入地研究這個項目時，我們意識到了幾件事：

1. 它已經解決了我們正在 Linkerd 2.12 中處理的一個主要問題：如何以一種全面、可組合、kubernetes 式的方式描述一類 HTTP 流量（例如，“所有以/foo/開頭的東西”或“所有有這個封包頭的東西”）。
2. 雖然已經計劃在 Linkerd 中添加 CRD，但我們并不情願，而 Gateway API 資源已經是 Kubernetes 的一部分。
3. 它的設計很好。真的很好。雖然它最初是為處理 Ingress 配置而設計的，但核心原語足夠靈活，而且可組合，是以，它實際上也适用于服務網格用例。

是以，我們放棄了最初的計劃，轉而采用Gateway API作為Linkerd授權政策的核心配置機制。盡管這會使 2.12 版本的釋出推遲幾個月，但我們知道，這是在為 Linkerd 的采用者做正确的事。

這個決定已經有了回報。在即将釋出的 2.13 版本中，我們将利用 Gateway API 資源類型來實作諸如基于頭的路由和可配置的斷路等功能。Linkerd 還參與了GAMMA計劃，這是 Gateway API 中的一個項目，目的是更好地追蹤服務網格用例。

延伸閱讀：Linkerd和Gateway API。

驚喜 2：eBPF 是一項優化，而不是遊戲規則改變者

當圍繞服務網格 eBPF 的讨論在 2022 年年初達到頂峰時，我們決定進行更深入的研究。我們發現，那并沒有我們希望的那麼引人注目。雖然 eBPF 可以簡化一些基本的服務網格任務，如轉發原始 TCP 連接配接，但如果沒有使用者空間元件，它根本就無法處理 HTTP/2、mTLS 或其他 L7 任務，這意味着它無法帶來根本性的改變——即使使用 eBPF，服務網格在叢集上某個地方仍然會需要 L7 代理。

尤其是被大肆吹捧的“無邊車 eBPF 服務網格”模型，感覺在可操作性和安全性方面是重大的倒退。将那種邏輯移到針對每個主機的 Envoy 代理中，将網絡問題和節點上所有東西的 TLS 密鑰資料混合在一起，這徹底違背了我們将事物容器化的初衷。eBPF 不是每個主機都需要的方式，營銷資料中卻将兩者混為一談，我們對此感到失望。

未來，我們确實計劃研究将 eBPF 作為一種簡化 Linkerd L4 特性集的方法，不過，将關鍵代碼轉移到核心中的前景還是讓我們感到擔憂，因為在核心中調試、觀察和推理都非常困難。(更不用說eBPF引入的新的令人興奮的攻擊向量了。)

總的來說，我們對 eBPF 的調查并沒有讓我們真正相信 eBPF。但是與以往任何時候相比，我們都更相信邊車仍然是服務網格的最佳模型，無論是出于操作還是安全考慮。

延伸閱讀：eBPF、邊車和服務網格的未來。

驚喜 3：Ambient Mesh

很快，Istio 的無邊車“Ambient Mesh”模式加入了無邊車 eBPF 服務網格，該模式組合使用每主機和每服務代理。深入研究這種方法是我們的又一個學習經曆。我們很高興地看到，它的安全性更好，至少在這裡是這樣：例如，不同身份的 TLS 密鑰資料在單獨的程序中維護。

然而，取消邊車的代價非常大：需要大量的新機器，其結果有很大的局限性，而且對性能有重大的影響。

總的來說，我們得出的結論是，它在生命周期管理和資源消耗方面的改進對 Linkerd 的用例并沒有助益。我們的感覺是，Ambient Mesh 比其他任何東西都更能解決大規模運作 Envoy 的問題。

意料之中的事 1：容器排序仍然是 Kubernetes 的弱點

除了驚喜，2022 年，我們還看到了一些意料之中的情況。與前幾年一樣，Linkerd 的采用者繼續與長期困擾 Kubernetes 的問題——缺少對容器排序的控制——做鬥争。這展現在多個方面：

• 需要通路網絡的 Sidecar 容器需要在 linkd-init 容器之後運作；
• 終止的作業需要有一種方式可以向其代理元件發出終止信号；
• 重新啟動或添加到現有叢集的節點需要一種方法來暫停 Linkerd 網絡初始化，直到 CNI 層初始化完成；
• 等等。

在特定的情況下，這些問題都是可以解決的。但對于服務網格采用者來說，這類問題仍然是一個麻煩，并且嚴重地違反了我們的原則，即服務網格應該對應用程式透明。然而，随着臭名昭著的邊車KEP走上了這條愚蠢的道路，我們可能還要忍受更長的時間。

雖然，關于另一個 KEP 的謠言甚嚣塵上……

就是這樣，但經過多次讨論，我認為我們現在對如何做一種每個人都可以接受的形式有了很好的了解:)

——蒂姆·霍金（thockin.yaml）（@thockin）2022年11月11日

延伸閱讀：在啟動時到底發生了什麼：Linkerd、初始化容器、CNI等等。

意料之中的事 2：安全性仍然是采用 Linkerd 的主要動力

與前幾年一樣，采用 Linkerd 的主要動力仍然是安全性。Linkerd 的零配置Mutual TLS一直是該項目的一個主要吸引力來源，2022 年引入的L7授權政策完善了 Linkerd 的零信任特性集。

我們也很高興地看到，市場顯現出了日益成熟的迹象。幾年前，“我們需要在傳輸過程中加密”是采用 mTLS 的主要理由。2022 年，我們聽到許多采用者說，“是的，我們需要在傳輸過程中加密，但也需要使用真實的工作負載辨別進行身份驗證，以及在每個 Pod 上實作零信任授權”。零信任正變得越來越受歡迎，這已經不是什麼秘密了，基于邊車的服務網格如果不直接實作零信任原則，就什麼都不是。邊車模型再得一分！

像往常一樣，我們也盡量保持項目的整潔，Linkerd出色地完成了年度安全審計。

2023 年服務網格會帶來什麼？

2023 年有望成為 Linkerd 公司又一個輝煌的年份。我們已經有了一些令人興奮不已的計劃，從即将釋出的 2.13 版本（包括基于頭的路由和斷路），到其他一些目前還保密的殺手級想法。一如既往，我們将專注于保持 Linkerd 簡單、輕便和安全。

想參與 CNCF 第一個也是唯一一個畢業的服務網絡嗎？現在就是加入的好時機。

原文連結：

https://linkerd.io/2022/12/28/service-mesh-2022-recap-ebpf-gateway-api/index.html