本篇文章發布至今已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
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 使描述更廣泛的路由配置和模型成為可能。
Kubernetes 中從 Ingress API 到 Gateway API 的過渡是由 Gateway API 提供的優勢和進階功能所驅動的,其基礎建立在四個核心原則之上:面向角色的方法、可攜性、表現力和可擴展性。
面向角色的方法
Gateway API 採用面向角色的方法,該方法與組織內參與配置 Kubernetes 服務網路的傳統角色保持一致。這種方法使基礎設施工程師、叢集運營商和應用程式開發人員能夠共同處理 Gateway API 的不同方面。
例如,基礎設施工程師在部署 GatewayClasses 方面發揮著關鍵作用,GatewayClasses 是叢集範圍的資源,充當範本,用於明確定義從它們衍生的 Gateway 的行為,為穩健的服務網路奠定基礎。
隨後,叢集運營商利用這些 GatewayClasses 來部署閘道。Kubernetes Gateway API 中的 Gateway 定義了外部流量如何定向到叢集內的服務,本質上是將非 Kubernetes 來源橋接到 Kubernetes 感知的目的地。它代表了符合 GatewayClass 規範的負載平衡器配置請求。Gateway 規範可能並不詳盡,因為某些細節可以由 GatewayClass 控制器提供,以確保可攜性。此外,Gateway 可以連結到多個 Route 參考,以將特定的流量子集導向指定的服務。
最後,應用程式開發人員配置路由資源(例如 HTTPRoutes),以管理配置(例如超時、請求匹配/篩選)和服務組合(例如到後端的路徑路由)。路由資源定義了協議特定的規則,用於將來自 Gateway 的請求映射到 Kubernetes 服務。HTTPRoute 用於多路複用 HTTP 或終止的 HTTPS 連線。它旨在用於您想要檢查 HTTP 流並使用 HTTP 請求數據進行路由或修改的情況,例如使用 HTTP 標頭進行路由,或在傳輸中修改它們。
可攜性
憑藉 20 多個 API 實作,Gateway 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 資源 (目前僅限 Gateways 和 HTTPRoutes)。如需其他選項,您可以執行帶有
-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 旨在改進目前的 Kubernetes 網路標準(如 Ingress),並減少對實作特定註解和 CRD 的需求。
它是一個 Kubernetes 標準 API,在不同的平台和實作中保持一致,最重要的是它具有前瞻性。Gateway API 是 Ingress 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 實作