面向未來的閘道器： Kubernetes Gateway API 和 Envoy Gateway

最近 Envoy Gateway 0.2 釋出了，API 閘道器的生態系統迎來了新的變化。這篇文章將想你介紹 Kubernetes API 閘道器領域的新進展。

如何將外部的網路請求路由到 Kubernetes 叢集?你可以使用入口控制器：一組 HTTP 反向代理，將流量轉接到叢集中，並由 operator 來管理。也可以使用 Ambassador、Contour、Traefik 或 HAproxy 這類軟體。還可以使用雲提供商的解決方案，或者只是用預設的的 Nginx Ingress。或者你可能使用一個功能更全面的 API 閘道器，如 Tyk 或 Kong，或者在 Kubernetes Ingress 前面的另一層有一個單獨的閘道器，如 AWS 的 API 閘道器，或內部的 F5，可以選擇的實在太多。

為什麼我們需要一個新的入口控制器

因為很多入口控制器都有不同程度的限制：有些是基於舊的技術，如 Nginx、HAproxy，甚至是基於 Apache 建立的。這些技術的特性不適用於雲原生環境，比如在配置改變時放棄已建立的連線(如果你想深入瞭解，Ambassador 發表了一篇比較文章)。雲供應商的產品確實傾向於基於更現代的東西(比如 SDN[3])，但是這可能產生廠商鎖定。目前，你只需用一個 Kubernetes API 來指定所有不同選項的配置：Ingress。這個 API 的可配置項很少，幾乎任何你想配置的設定都需要透過 annotation 來實現，而不是作為一類欄位。

Envoy Gateway：未來 Gateway 發展的基礎

現在又有了新的選擇：Envoy Gateway，簡稱 EG。顧名思義，這是一個基於 Envoy 代理的閘道器(入口控制器)。它是一個託管在 GitHub 上的 Envoy 社群專案。除了這個基於 Envoy 的入口;已經有流行的建立在 Envoy 之上的 Contour 和 Ambassador 等專案。但是這些專案的開發者和更多的人正在一起為 EG 做出貢獻，Ambassador 和 Contour 都說他們會在適當的時候在 Envoy Gateway 的程式碼上重構(也就是說，我們 Tetrate 公司無可否認地為我們在這個專案中的領導作用感到自豪)。

Envoy 本身是久經考驗的入口代理、sidecar 代理，並且正在準備取代谷歌的 GFE。

程式碼演示

如果你想在瞭解更多關於 Envoy Gateway 的內容之前先演練一番，我已經寫了一篇姐妹篇 ，其中有詳細的說明，可以自己設定 Envoy Gateway，如果你沒有環境，那篇文章中也包括了我機器上所有的命令輸出，這樣你就可以看到會發生什麼。

通往 API 的 Gateway

Envoy Gateway 以其最簡單的形式 —— 你可能剛剛設定好的系統，將請求轉發到其叢集中。它根據 HTTP host 和 path 進行路由，也可以根據其他 header 進行路由。每個叢集都需要這樣做，很高興看到 Envoy Gateway 在開發的短短 6 個月內就能做到這一點(要了解更多關於 Envoy Gateway 的資訊，請看 Gateway to a New Frontier。

超越基本入口的高階功能

然而，許多組織需要比這個基本的 7 層網路路由更多的功能。如果需要像 WAF、body 的模式驗證、bot 攔截等，許多人就會使用 API 閘道器。我們看到很多組織在他們的入口控制器前面部署了一個單獨的 API 閘道器。然而，API 閘道器可以取代入口控制器，因為它也可以做路由和流量觀察的基本功能。它們可以提供這些功能，因為它們是由與入口控制器相同的代理構建的，例如，Kong 是基於 nginx 的。API 閘道器產品在市場上很受歡迎，但如果你真的想一想 API 閘道器是什麼，它就是一個 HTTP 代理，有一系列的附加功能(我之前提到的 WAF 等)。這並不是說它們不增加任何價值 —— 它們提供的功能是多種多樣的，而且很強大，但有一個共同的功能基線和實現程式碼。

使用 Wasm 的動態可擴充套件性

因此，Envoy Gateway 完全有能力發展成為一個全功能的 API 閘道器。Envoy 實際上已經具備了一些更先進的功能，包括 JWT 驗證、OIDC 認證流和速率限制。此外，Envoy 是動態可擴充套件的;它可以在不重啟的情況下載入外掛，這意味著可以很容易地按需新增更多的功能。這些外掛是以 WASM 位元組碼的形式提供的，這意味著它們可以用任何可以編譯成 WASM 的語言(Tiny Go、Rust 等)編寫，而不僅僅是其他代理支援的指令碼語言。社群正在開始編寫這些外掛：快取可能會首先落地，Coraza[8] 專案是一個相對成熟的 mod_security 風格的 WAF，用 Go 編寫，可以編譯成 WASM，現在可以用於 Envoy 代理。

Gateway API 鼓勵擴充套件

在入口控制器市場上，擴充套件和競爭的另一大障礙是 API。需要特定於供應商的註解(或全新的特定於供應商的 API)，這些註解很笨重，而且妨礙了交叉相容。相比之下，Envoy Gateway 是由 Gateway API 配置的，這是 gateway.networking.k8s.io API 組的一組資源。這個 API 將最終取代 Ingress 資源。它的核心已經比 Ingress 更加靈活和富有表現力，而且它被設計成以可管理的方式增長和擴充套件。這將允許它發展成為所有南北流量控制的模型，從基本的路由到先進的 API 管理功能。這反過來又會將 Envoy Gateway 擁有的所有功能，以一種標準的、與供應商無關的方式暴露出來，讓人們在使用這些功能時無需跳過障礙或擔心鎖定問題。Envoy Gateway 將在 2023 年 3 月的 0.3 版本中支援 Gateway API 的這些新部分。

為未來的閘道器發展提供一個共同的的基礎

Envoy Gateway 的動力來自於對 API 閘道器功能堆疊的日益關注。基本的入口正在變得商業化，所以社群正在彙集其資源和專業知識，為未來的閘道器開發創造一個共同的基礎。同時提供新的 Gateway API 供其實現是非常方便的，Envoy Gateway 的 0.2 版本標誌著對目前定義的 Gateway API 核心型別的全面支援。

擴充套件到高階用例模型的工作已經開始，現在正在設計 JWT auth 配置，其他的也將陸續推出。外掛本身的工作也已經開始(例如，Coraza，一個仿照無處不在的 mod_security 的 Golang WAF)。雖然這些都有很長的路要走，但我個人非常期待看到這一切在未來一兩年的發展。

通往服務網格的 Gateway

你可能在想，已經有一類產品支援 OIDC 認證和速率限制等功能了：服務網格。這是真的;最突出的網格，Istio，在其預設配置中為入口部署了一套代理伺服器。Istio 現在支援 Gateway API(就像 Envoy Gateway 一樣)來配置該入口。我們在 Tetrate 對這種融合感到興奮：企業現在可以採用 Envoy Gateway 來簡單而快速地開展工作。Envoy Gateway 在管理這種南北流量方面做得很好，執行它可以讓他們瞭解 Envoy 在生產中的效能和操作特點。當這些組織準備好控制他們的服務到服務，也就是東西向流量時，他們可以部署 Istio，因為他們已經熟悉了主要的基礎元件(Envoy)。雖然他們可能會選擇使用 Istio 的入口閘道器(以保持他們的控制平面數量減少到 1)，但他們現有的 Gateway API 資源將繼續工作。由於同樣基於 Envoy，Istio 的 Ingress 也可以接受任何載入到 Envoy Gateway 的 API Gateway 風格的外掛。所有這一切都使得在必要時增加服務網格的力量變得非常容易。

用於入口和服務網格的統一 Gateway API

更重要的是，現在已經有了一個工作組來協調閘道器和網格網路之間的重疊部分：GAMMA 倡議 [10]。GAMMA 是 Gateway API for Mesh Management and Administration 的縮寫，這是對 Gateway API 未來發展方向的一個倡議;計劃是開始對服務網格的關注進行建模，即東西向流量也是如此。GAMMA 將確保 Envoy Gateway 和服務網格的良好合作，並將關注 Gateway API 的統一，以涵蓋入口和網格。我們很高興看到，這將為許多組織輕鬆和逐步地採用服務網格，基於一個與產品無關的 API，這對所有人都是好事。

結束語

這篇文章對新的標準 API、Gateway API 和參考實現 Envoy Gateway 作了很好的介紹，希望能對你瞭解當前的入口閘道器生態有所幫助。

如果你想關注 EG 的發展，你可以加入 Envoy slack 的 #gateway 頻道，並在 檢視提交和問題。該專案有一個 未來幾個版本的路線圖 ，0.3.0 版本釋出預期是在 2023 年 3 月。

如果你想測試一下 Envoy Gateway，我寫了一個配套的教程，其中包含了啟動和執行的步驟說明。

如果你正在開始使用 Istio 和 Envoy，請檢視 Tetrate 學院，你會發現大量的免費課程、研討會，以及 Tetrate 的 Istio 管理員認證考試。

要想以最簡單的方式安裝、管理和升級 Istio，請檢視開源 Tetrate Istio 發行版(TID)[13]。TID 是一個經過審查的 Istio 的上游發行版 ——Istio 的加固映象，具有持續的支援，更容易安裝、管理和升級。