NGINX Ingress Controller 2.0 版:那些你不得不知道的事兒

語言: CN / TW / HK

原文作者:Brian Ehlert of F5, Jenn Gile of F5
原文連結:​​NGINX Ingress Controller 2.0 版:那些你不得不知道的事兒 - NGINX​
轉載來源:NGINX官方網站


(首次釋出於2021.12.27)

10 月份,我們推出了 F5 NGINX Ingress Controller 2.0 版(​​nginxinc/kubernetes-ingress​​​),增加了對 ​​Kubernetes 1.22​​​ ​和 ​Ingress API V1​​​​networking.k8s.io/v1​​​)的支援​。您可能會想,​那又怎樣呢?

“那又怎樣”是一個很微妙的問題,我們可以從三個相互關聯的問題中一探究竟:

請繼續閱讀本文尋找答案,敬請關注將於 2022 年 1 月 11 日釋出的 《Kubernetes 版本攻擊應對計劃》


為什麼 Kubernetes 的釋出事關重大?

這個問題的答案既簡單又複雜。Kubernetes 的相容性管理極具挑戰性,原因是 Kubernetes 操作員必須管理​三種​版本:

  1. The Kubernetes 平臺本身​ —— Kubernetes 團隊每釋出一個新的 Kubernetes 版本,就會停止維護上一個舊版本。對於您的風險管理策略而言,繼續使用這樣的老版本是個問題,並且由於 Kubernetes 團隊不再提供支援,故障排除也將變得更加困難。目前,Kubernetes 專案正在維護的是三個最新子版本(1.20、1.21 和 1.22)分支。Kubernetes 1.19 及更高版本的補丁支援持續了 1 年左右,而 1.18 及更早版本的補丁支援為期 9 個月左右。(1.18 及更早版本的支援時間較短,是因為 Kubernetes 過去每年釋出四次,而現在每年釋出三次)。

  2. Kubernetes API​ —— 每次 Kubernetes 釋出時,都會有新的 API 誕生,而過時的 API 會被棄用,API 的變化將會影響相應的資源和工具。升級 Kubernetes 平臺可能還需要升級 API。

  3. 部署在 Kubernetes 中的工具​ —— Kubernetes 或其 API 的重大變更可能會影響您的工具(例如 Ingress Controller)以及相應資源的正常執行。

因此,您需要跟蹤三個時間線:Kubernetes 時間線、Ingress API 時間線及 NGINX Ingress Controller 時間線。為了避免破壞 Kubernetes,您必須找到讓 Kubernetes 版本與 API 和 NGINX Ingress Controller 相容的最佳平衡點。如果不檢查相容性就升級其中任何一個元件,就會產生嚴重的後果。如果這三個元件不能相互相容,那您就有麻煩了!


什麼是 Ingress API,為什麼 ​​networking.k8s.io/v1​​ 至關重要?

Ingress Controller 可通過 Ingress API 安全地暴露您的 Kubernetes 應用。Kubernetes 1.19 就已經引入了 ​​networking.k8s.io/v1​​​ API(又叫 Ingress API v1)。 那時候,Kubernetes 同時支援 ​​v1beta1​​​ 和 ​​v1​​,並會自動將兩種版本呈現為同一個版本。雖然 API 版本的這種“幕後”相容性為您帶來了操作上的便利,但同時也會為您的工作計劃帶來阻礙。

隨著 Kubernetes 1.22 的釋出,Ingress API 就只有 ​​v1​​​ 版了。這一點很重要,因為這種唯一性讓所有 beta 版本(​​extensions/v1beta1​​​ 和 ​​networking.k8s.io/v1beta1​​)都被淘汰了。雖然這對尚未採用 Ingress API v1 的企業造成了巨大沖擊,但我們認為這種變化未嘗不是一件好事。這標誌著 Ingress API 正式從 beta 版發展為成熟且完全實現的 API。那麼,為什麼這種變化很重要?這又回到了版本管理的問題上。假設您將現有叢集升級到 Kubernetes 1.22,但仍然使用與 v1beta1 Ingress 相關的資源,那麼您的 Ingress 資源就麻煩了!


NGINX Ingress Controller 2.0 對當前客戶有何影響?

由於 NGINX Ingress Controller 與 Ingress API 緊密耦合,​​v1​​ 的釋出對作為產品提供商的我們以及作為客戶的您產生了重大影響,因此我們直接將 NGINX Ingress Controller 的版本號從 1.​x​ 跳到了 2.​x​。我們重新構建了 NGINX Ingress Controller 2.0,使其能夠利用 Ingress API v1 以及與 Kubernetes 1.22 完全相容。

如果您使用 NGINX Ingress Controller,您需要立即根據版本採取相應的措施,以免破壞 Kubernetes、您的 Ingress 資源或 NGINX Ingress Controller:

Kubernetes 1.18 及更早版本:

  • 確保您使用的是 NGINX Ingress Controller 1.12,以充分利用可用的功能集。(當您升級到 NGINX Ingress Controller 2.0 時,您還需要升級到 Kubernetes 1.19 或更高版本。)

  • 制定一個計劃,在未來幾個月內遷移到更新的 Kubernetes(和 NGINX Ingress Controller)版本,因為一旦釋出新的 Kubernetes 版本,Kubernetes 1.18 就不再受支援。

Kubernetes 1.19–1.21:

  • 升級到 NGINX Ingress Controller 2.0。

  • 如果您尚未將 Ingress 相關資源遷移到 ​​networking.k8s.io/v1​​​(請參閱 ​​NGINX Ingress Controller 2.0 發行說明​​​請立即制定計劃。Kubernetes 1.19–1.21 支援當前的所有 Ingress API(包括 ​​v1beta1​​​ 和 ​​v1​​)版本,您可以隨時進行轉換。

  • 如果您還沒有轉換,請立即將您的 Ingress 和 IngressClass 資源遷移到 ​​networking.k8s.io/v1​​。

  • 如果您在 Ingress 資源中正在使用已經棄用的 ​​kubernetes.io/ingress.class​​​ 註釋,我們建議您切換到 ​​ingressClassName​​ 欄位。

  • 請參考我們的​​文件與示例​​​(與 ​​networking.k8s.io/v1​​​ 和 Ingress 資源的 ​​ingressClassName​​ 欄位一起提供)來制定更新計劃。

Kubernetes 1.22:

  • 確保您已執行 NGINX Ingress Controller 2.0,因為之前版本的 NGINX Ingress Controller 與 Kubernetes 1.22 不相容並且不支援 Ingress API v1。

NGINX Ingress Controller 的發展史

NGINX Ingress Controller 於 2016 年首次釋出,從一個稚嫩的工具發展至今已經成為了 Kubernetes 網路流量管理的強大工具。以下是 NGINX Ingress Controller 從釋出之初至今的演變過程。

2016 年(​​v0.5.0​​)

NGINX 工程師 Michael Pleshakov 在我們的 GitHub 倉庫(​​nginxinc/kubernetes-ingress​​​)中釋出了第一個版本,使得將 NGINX 和 F5 NGINX Plus 用作 Kubernetes Ingress Controller (KIC) 成為可能。

NGINX Ingress Controller 在 2016 年歐盟 KubeCon 大會上首次亮相。檢視​​視訊記錄​​:第 1 天,藉助 NGINX 為 Kubernetes 建立高階負載均衡解決方案;2016 年歐盟 KubeCon 大會。

2017 年(​​v1.0.0​​)

該專案已完成生產準備,其中 NGINX Plus 版本增加了對 JSON Web Token (JWT) 的關鍵支援。

在 2017 年 NGINX Conf 大會上,Michael Pleshakov 展示了生產級功能,包括高階負載均衡功能,即在​​Kubernetes 上將 NGINX Plus 用作負責應用負載均衡的 Ingress Controller​​。

2018 年

NGINX Ingress Controller 的視覺化、易用性和靈活性大大增強:

在 2018 年 NGINX Cenf 大會上,Michael Pleshakov 展示了​​如何將 NGINX 用作 Kubernetes Ingress Controller​​,並分享瞭如何使用 Helm 部署 NGINX Ingress Controller、配置 HTTP 和 TCP/UDP 負載均衡、通過 Prometheus 監控及故障排除。

2019 年

我們首次推出了標準 Kubernetes Ingress 資源的替代方案,使高階功能的執行變得更容易、更可靠。

在​​《下一代 NGINX Ingress Controller》​​中,Michael Pleshakov 再次現身 2019 年 NGINX Conf 大會,演示了 VS/VSR 的用例,包括藍綠部署和 A/B 測試。

2020 年

除了 NGINX Ingress 資源的眾多增強功能之外,今年的主題是與生態系統工具和 NGINX 產品相整合。

在 ​​《藉助 NGINX 和 OpenShift 保護生產應用》​​中,技術營銷工程師 Amir Rawdat 演示瞭如何使用 NGINX Ingress Operator、利用 RBAC 進行跨功能配置、藉助 NGINX App Protect 保護容器化應用以及及藉助 JWT 驗證客戶端。

2021 年

安全防護是主旋律,並且越來越多關於生態融合的進展:

在 NGINX Sprint 2.0 線上大會中,軟體工程師 Aidan Carson 在他的演講​​“掌握微服務的端到端加密”​​中演示瞭如何用 NGINX Ingress Controller 防護邊緣節點、如何利用 NGINX Service Mesh 在服務間構建安全訪問控制,以及如何利用二者及 mTLS 來保護出向流量。


下一步:試用 NGINX Ingress Controller

如果您認為開源 Ingress Controller 對您的應用來說是最好的選擇,那麼您可前往 ​​GitHub 倉庫​​,立即下載 NGINX 開源版 NGINX Ingress Controller。

如果是大型生產部署,您不妨試試基於 NGINX Plus 的商業版 NGINX Ingress Controller。它提供 ​​30 天免費試用版​​,其中包括 NGINX App Protect。


更多資源

想要更及時全面地獲取NGINX相關的技術乾貨、互動問答、系列課程、活動資源?

請前往NGINX開源社群: