為什麼我們決定從零開始建立 NGINX Gateway Fabric

Gateway API 是 Ingress 資源的演進,重建了 Kubernetes 中處理互聯的方式。 在這篇文章中,我們討論了為什麼我們選擇建立 NGINX Gateway Fabric 這一全新實現,而非在已有的 NGINX Ingress Controller ......

在 Kubernetes Ingress controllers 領域,NGINX 取得了巨大成功。 NGINX Ingress Controller 被廣泛部署用於商業 Kubernetes 生產用例,同時也作為開源版進行開發和維護。 因此,您可能會想當然地認為,當Kubernetes 網路(Gateway API)獲得重大改進時,我們會再進一步,將其部署到我們的現有 Ingress 產品中。

然而,我們選擇了一條不同的道路。 通過評估全新 Gateway API 的強大潛能以及是否有可能徹底重塑Kubernetes 中的互聯處理方式,我們意識到將 Gateway API 實現強塞到現有 Ingress 產品中會限制未來發展。

因此,我們決定推出自己的 Gateway API 專案 — NGINX Gateway Fabric。 該專案是開源專案,將以透明、協作的方式運行。 我們很高興與外部貢獻者合作,並樂於分享最新成果,共同推動創新,造福於整個社群和行業。

我們為什麼決定推出自己的 Gateway API 專案

儘管我們滿懷信心做出了圍繞 Gateway API 建立一個全新項目的決定,但這一決定也基於合理的業務和產品戰略邏輯。

想必 Kubernetes 採用者已經對 NGINX Ingress Controller 的開源版和商業版有所瞭解。 兩者都部署了經過嚴格測試的 NGINX 數據平面(在 NGINX Plus 和 NGINX 開源版反向代理中運行)。 在 Kubernetes 之前,NGINX 的數據平面已在負載均衡和反向代理用例中有不凡表現。 在 Kubernetes 中,我們的 Ingress controller 可完成相同類型的關鍵請求路由和應用交付任務。

NGINX 因輕量級、高性能、久經考驗並可滿足嚴苛環境要求的商業產品而享負盛名。 我們在 Kubernetes Ingress controller 領域的產品戰略與我們的反向代理產品策略相一致,即為簡單用例提供強大的開源產品,併為關鍵業務應用環境中的生產 Ingress 控制提供具有更多特性和功能的商業產品。 這一策略在 Ingress controller 領域中行之有效,部分原因是過去 Ingress controller 缺乏標準化,需要大量自定義資源定義(CRD)來提供負載均衡和反向代理進階功能,開發人員和架構師在 Kubernetes 以外的網路產品中享用這些進階功能。

我們的客戶依賴並信任 NGINX Ingress Controller,其商業版本已經具備了 Gateway API 旨在提供的許多關鍵進階功能。 此外,NGINX 很早就參與了 Gateway API 專案,並認識到 Gateway API 生態系統要達到完全成熟還需要幾年的時間。 (事實上,Gateway API 的許多規範都在不斷演進,例如 GAMMA 規範,該規範有助於更好地整合 service mesh(服務網格)。 )

但我們認為,將測試級 Gateway API 規範強塞到 NGINX Ingress Controller 中會給成熟的企業級 Ingress controller 帶來無謂的不確定性和複雜性。 我們銷售的任何產品都必須具有穩定性和可靠性,並完全符合生產就緒要求。 Gateway API 解決方案也會做到這一點,只是目前仍處於起步階段。

我們的 NGINX Gateway Fabric 目標

對於 NGINX Gateway Fabric,我們的主要目標是打造一款經得起時間考驗的產品,就像 NGINX Plus 和NGINX 開源版一樣。 為了確保我們的 Gateway API 專案能夠「滿足未來需求」,我們意識到需要為其數據平面和控制平面嘗試不同的架構選擇。 例如,我們可能需要研究不同的方法來管理四層和七層互聯或盡量減少外部依賴項。 我們最好從零開始,而不沿襲任何歷史先例和遵從任何要求。 雖然我們正在使用業經試用和測試的 NGINX 數據平面作為 NGINX Gateway Fabric 的基礎元件,但對新想法也持開放態度。

我們還希望為 Gateway API 資源提供不受廠商限制的全面配置互操作性。 與現有 Kubernetes Ingress 範式相比,Gateway API 最大的改進之一就是規範了服務網路的許多元件。 從理論上講,這種標準化可支援許多Gateway API 資源輕鬆地進行交互和連接,助力創造更加美好的未來。

不過,創造這一未來的關鍵是摒棄廠商特定的 CRD(可能導致廠商鎖定)。 對於必須支持專為 Ingress controller 領域而設計的 CRD 的混合產品而言,這可能極具挑戰性。 而在以互操作性為第一要務的開源專案中,做到這一點則相對容易些。 為了摒棄緊密關聯的 CRD,我們需要構建一個新框架,僅關注 Gateway API 及其組成 API 所暴露的新層面。

加入我們的 Gateway API 之旅

目前,我們仍處於早期發展階段。 只有少數專案和產品實施了 Gateway API 規範,其中大多數都選擇將其融入現有專案和產品中。

因此,現在是啟動新專案的最佳時機。 我們的 NGINX Gateway Fabric 專案完全開放,決策和專案管理高度透明。 因為該專案使用 Go 編寫而成,所以我們誠邀廣大 Gopher 社群成員建言獻策、提交 PR。

Gateway API 可能會改變整個 Kubernetes 世界。 一些產品可能不再需要,新的產品或將出現。 Gateway API 蘊藏著無限可能,雖然不知道它終將走向何方,但我們翹首以待。 誠邀您加入我們,共創精彩未來!

文章來源:NGINX