本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
介紹 ingress2gateway;簡化到 Gateway API 的升級
今天,我們釋出了 ingress2gateway,這是一款可以幫助你從 Ingress 遷移到 Gateway API 的工具。Gateway API 距離正式釋出(GA)只有幾周時間了,如果你還沒有升級,現在是時候考慮了!
背景
在不斷發展的 Kubernetes 世界中,網路扮演著至關重要的角色。隨著越來越多的應用程式部署在 Kubernetes 叢集中,如何有效地將這些服務暴露給客戶端成為一個關鍵問題。如果你一直在使用 Kubernetes,你可能對 Ingress API 很熟悉,它一直是管理對服務的外部訪問的首選解決方案。
Ingress API 提供了一種將外部流量路由到叢集內應用程式的方法,使其成為許多 Kubernetes 使用者不可或缺的工具。然而,Ingress 也有其侷限性,隨著應用程式變得越來越複雜,以及對 Kubernetes 叢集的需求增加,這些侷限性可能會成為瓶頸。
其中一些限制是
- 通用功能不足 - 透過嘗試為各種 HTTP 代理建立一個通用的功能集,Ingress 只能支援基本的 HTTP 路由,這迫使現代代理的更多功能,如流量分割和頭部匹配,都必須透過特定於提供商且不可移植的註解來實現。
- 許可權模型不完善 - Ingress 規約將基礎設施和應用程式的配置都放在一個物件中。使用 Ingress 時,叢集操作員和應用程式開發人員在同一個 Ingress 物件上操作,而沒有意識到彼此的角色。這導致了基於角色的訪問控制不足,並且很容易出現配置錯誤。
- 協議多樣性不足 - Ingress 主要關注 HTTP(S) 路由,不為 TCP、UDP 和 gRPC 等其他協議提供原生支援。這一限制使其不太適合處理非 HTTP 工作負載。
Gateway API
為了克服這些問題,Gateway API 旨在提供一種更靈活、可擴充套件且功能強大的方式來管理服務的流量。
Gateway API 距離正式釋出(GA)只有幾周時間。它為入口流量控制提供了一個標準的 Kubernetes API。它提供了擴充套件的功能、改進的定製化和更大的靈活性。透過專注於模組化和富有表現力的 API 資源,Gateway API 使得描述更廣泛的路由配置和模型成為可能。
從 Ingress API 向 Gateway API 的過渡,是由 Gateway API 提供的優勢和高階功能所驅動的,其基礎建立在四個核心原則之上:面向角色、可移植性、表現力和可擴充套件性。
面向角色的方法
Gateway API 採用了一種面向角色的方法,這與組織內參與配置 Kubernetes 服務網路的傳統角色相一致。這種方法使基礎設施工程師、叢集操作員和應用程式開發人員能夠共同處理 Gateway API 的不同方面。
例如,基礎設施工程師在部署 GatewayClass 中扮演著關鍵角色。GatewayClass 是叢集範圍的資源,作為模板明確定義了從它們派生的 Gateway 的行為,為穩健的服務網路奠定了基礎。
隨後,叢集操作員利用這些 GatewayClass 來部署閘道器。在 Kubernetes 的 Gateway API 中,Gateway 定義了外部流量如何被引導到叢集內的 Service,本質上是連線非 Kubernetes 源和 Kubernetes 感知目標。它代表了與 GatewayClass 規範一致的負載均衡器配置請求。Gateway 規約可能不是詳盡無遺的,因為一些細節可以由 GatewayClass 控制器提供,從而確保可移植性。此外,一個 Gateway 可以連結到多個路由引用,以將特定的流量子集引導到指定的服務。
最後,應用程式開發人員配置路由資源(如 HTTPRoutes),以管理配置(例如超時、請求匹配/過濾)和服務組合(例如到後端的路徑路由)。路由資源定義了將請求從 Gateway 對映到 Kubernetes Service 的協議特定規則。HTTPRoute 用於複用 HTTP 或已終止的 HTTPS 連線。它適用於需要檢查 HTTP 流並使用 HTTP 請求資料進行路由或修改的場景,例如使用 HTTP 頭部進行路由,或在傳輸過程中修改它們。
可移植性
Gateway API 擁有超過 20 個 API 實現,其設計旨在更好地跨不同實現、叢集和環境進行移植。它有助於減少 Ingress 對不可移植、特定於提供商的註解的依賴,使你的配置在多個叢集中更加一致且易於管理。
Gateway API 承諾支援最新的 5 個 Kubernetes 小版本。這意味著 Gateway API 目前支援 Kubernetes 1.24+。
表現力
Gateway API 為廣泛的功能提供了標準的、由 Kubernetes 支援的功能,例如基於頭部的匹配、流量分割、基於權重的路由、請求映象等。而在 Ingress 中,這些功能需要自定義的、特定於提供商的註解。
可擴充套件性
Gateway API 將可擴充套件性作為其核心特性來設計。它不是強制採用一種“一刀切”的模型,而是在 API 框架的多個層級提供了連結自定義資源的靈活性。這種分層的定製方法確保使用者可以根據自己的特定需求定製配置,而不會使主要結構變得臃腫。透過這樣做,Gateway API 促進了更精細、更具上下文感知的調整,從而在標準化和適應性之間實現了微調平衡。這在複雜的雲原生環境中尤其有價值,因為特定的用例需要細緻入微的配置。一個關鍵的區別是,Gateway API 擁有更廣泛的基礎功能集和一種標準的擴充套件模式,這種模式比 Ingress 上的註解更具表現力。
升級到 Gateway
從 Ingress 遷移到 Gateway API 可能看起來令人生畏,但幸運的是,Kubernetes 剛剛釋出了一個簡化流程的工具。ingress2gateway 透過將你現有的 Ingress 資源轉換為 Gateway API 資源來協助遷移。以下是如何開始使用 Gateway API 和 ingress2gateway 的方法:
安裝 ingress2gateway。
如果你本地有 Go 開發環境,你可以用以下命令安裝
ingress2gateway
go install github.com/kubernetes-sigs/ingress2gateway@v0.1.0
這將把
ingress2gateway
安裝到$(go env GOPATH)/bin/ingress2gateway
。或者,請參考此處的安裝指南。
工具安裝後,你可以用它將叢集中的 Ingress 資源轉換為 Gateway API 資源。
ingress2gateway print
上述命令將:
- 載入你當前的 Kubernetes 客戶端配置,包括活動的上下文、名稱空間和身份驗證詳細資訊。
- 在該名稱空間中搜索 Ingress 和特定於提供商的資源。
- 將它們轉換為 Gateway API 資源(目前僅支援 Gateway 和 HTTPRoute)。對於其他選項,你可以使用
-h
引數執行該工具,或參考 https://github.com/kubernetes-sigs/ingress2gateway#options。
審查轉換後的 Gateway API 資源,驗證它們,然後將它們應用到你的叢集。
向你的 Gateway 傳送測試請求,檢查其是否正常工作。你可以使用
kubectl get gateway <gateway-name> -n <namespace> -o jsonpath='{.status.addresses}{"\n"}'
獲取閘道器地址。更新你的 DNS,使其指向新的 Gateway。
一旦你確認沒有更多流量透過你的 Ingress 配置,你就可以安全地刪除它。
總結
實現可靠、可擴充套件和可伸縮的網路一直是一個具有挑戰性的目標。Gateway API 旨在改進像 Ingress 這樣的現有 Kubernetes 網路標準,並減少對特定實現註解和 CRD 的需求。
它是一個 Kubernetes 標準 API,在不同平臺和實現之間保持一致,最重要的是,它面向未來。Gateway API 是 Ingress API 的下一代,但其範圍更廣,還擴充套件到處理服務網格和第 4 層路由。Gateway API 和 ingress2gateway 由 SIG Network 下的一個專門團隊支援,他們積極地進行開發並管理生態系統。它也很可能獲得更多的更新和社群支援。
未來的道路
ingress2gateway 才剛剛起步。我們計劃引入更多的提供商支援,增加對更多型別的 Gateway API 路由的支援,並確保一切與 Gateway API 的持續發展順利同步。
令人興奮的是,Gateway API 也在取得重大進展。雖然 v1.0 即將釋出,但仍有大量工作要做。此版本包含了許多新的實驗性功能,還有其他功能目前正處於規劃和開發的早期階段。
如果你有興趣參與貢獻,我們非常歡迎!請檢視社群頁面,其中包含了 Slack 頻道和社群會議的連結。我們期待你的加入!
有用的連結
- 在 GitHub 上參與 Ingress2Gateway 專案
- 提出新問題 - ingress2gateway, Gateway API。
- 加入我們的討論。
- Gateway API 入門
- Gateway API 實現