本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes 1.29：雲驅動整合現在是獨立的元件

作者：Michael McCune (Red Hat), Andrew Sy Kim (Google) |

對於 Kubernetes v1.29，你需要使用額外的元件來將你的 Kubernetes 叢集與雲基礎設施提供商整合。預設情況下，如果你嘗試使用舊的內建雲驅動整合來指定與任何雲提供商的整合，Kubernetes v1.29 元件將會**中止**。如果你想使用舊的整合，你必須重新選擇加入——而未來的版本將徹底移除這個選項。

2018 年，Kubernetes 社群同意成立雲驅動特別興趣小組（SIG），其任務是將所有云驅動整合外部化，並移除所有現有的樹內雲驅動整合。2019 年 1 月，Kubernetes 社群批准了 KEP-2395：移除樹內雲驅動程式碼 的初稿。該 KEP 定義了一個流程，透過該流程我們可以從 Kubernetes 核心原始碼樹中移除特定於雲驅動的程式碼。引自 KEP：

此項工作的動機是讓雲驅動商能夠獨立於核心 Kubernetes 釋出週期來開發和釋出版本。雲驅動程式碼的解耦允許在“Kubernetes 核心”和生態系統內的雲驅動商之間實現關注點分離。此外，這確保了生態系統中的所有云驅動商都以一致且可擴充套件的方式與 Kubernetes 整合。

經過多年的開發和眾多貢獻者的協作，舊的雲驅動整合的預設行為正在改變。這意味著使用者將需要確認他們的 Kubernetes 配置，並且在某些情況下需要執行外部的雲控制器管理器。這些變更在 Kubernetes 1.29 版本中生效；請繼續閱讀以瞭解你是否受到影響以及需要做出哪些更改。

這些更新的預設設定影響了大部分 Kubernetes 使用者，並且對於之前使用樹內驅動整合的使用者**將需要進行更改**。舊的整合提供了與 Azure、AWS、GCE、OpenStack 和 vSphere 的相容性；然而，對於 AWS 和 OpenStack，內建的整合已分別在 Kubernetes 1.27 和 1.26 版本中被移除。

有什麼變化？

在最基礎的層面上，兩個特性門控的預設值從 false 變為 true。這兩個特性門控，DisableCloudProviders 和 DisableKubeletCloudCredentialProviders，控制著 kube-apiserver、kube-controller-manager 和 kubelet 呼叫這些元件中包含的雲驅動相關程式碼的方式。當這些特性門控為 true（預設值）時，--cloud-provider 命令列引數唯一被識別的值是 external。

讓我們看看官方 Kubernetes 文件中關於這些特性門控的說明：

DisableCloudProviders：停用 kube-apiserver、kube-controller-manager 和 kubelet 中與 --cloud-provider 元件標誌相關的任何功能。

DisableKubeletCloudCredentialProviders：停用 kubelet 中用於向雲驅動容器映象倉庫進行身份驗證以獲取映象拉取憑證的樹內功能。

Beta 之後的下一階段將是完全移除；從該版本開始，你將無法將這些特性門控覆蓋回 false。

你需要做什麼？

如果你正在從 Kubernetes 1.28+ 升級，並且沒有使用 Azure、GCE 或 vSphere，那麼你無需做出任何更改。如果你**正在**使用 Azure、GCE 或 vSphere，或者你正在從低於 1.28 的版本升級，那麼請繼續閱讀。

歷史上，Kubernetes 包含了一組雲驅動的程式碼，包括 AWS、Azure、GCE、OpenStack 和 vSphere。自從 KEP-2395 啟動以來，社群一直在朝著移除這些雲驅動程式碼的方向努力。OpenStack 驅動程式碼在 1.26 版本中被移除，AWS 驅動程式碼在 1.27 版本中被移除。這意味著使用受影響的雲驅動商和版本的使用者在升級時需要修改他們的部署。

在 Azure、GCE 或 vSphere 上升級

在這種配置下升級有兩種選擇：遷移到外部雲控制器管理器，或者繼續使用樹內驅動程式碼。雖然建議遷移到外部雲控制器管理器，但在某些情況下，繼續使用當前行為也是可取的。請根據你的需求選擇最佳選項。

遷移到外部雲控制器管理器

在你的情況下，如果可能的話，遷移到使用外部雲控制器管理器是推薦的升級路徑。為此，你需要為 kube-apiserver、kube-controller-manager 和 kubelet 元件啟用 --cloud-provider=external 命令列標誌。此外，你還需要為你的提供商部署一個雲控制器管理器。

安裝和運行雲控制器管理器是一個比本文所能涵蓋的更大的主題；如果你想了解更多關於此過程的資訊，請閱讀雲控制器管理器管理和遷移複製的控制平面以使用雲控制器管理器的文件。有關特定雲驅動商實現的連結，請參閱下文。

繼續使用樹內驅動程式碼

如果你希望繼續使用帶有樹內雲驅動程式碼的 Kubernetes，你需要修改 kube-apiserver、kube-controller-manager 和 kubelet 的命令列引數，以停用 DisableCloudProviders 和 DisableKubeletCloudCredentialProviders 的特性門控。為此，請將以下命令列標誌新增到前面列出的命令的引數中：

--feature-gates=DisableCloudProviders=false,DisableKubeletCloudCredentialProviders=false

請注意，如果你的命令列上還有其他特性門控修改，它們將需要包含這兩個特性門控。

注意：這些特性門控將在即將釋出的版本中鎖定為 true。將這些特性門控設定為 false 應作為最後的手段。強烈建議遷移到外部雲控制器管理器，因為樹內驅動計劃最早在 Kubernetes 1.31 版本中移除。

在其他提供商上升級

對於 Azure、GCE 或 vSphere 以外的提供商，好訊息是，外部雲控制器管理器應該已經在使用中。你可以透過檢查叢集中 kubelet 的 --cloud-provider 標誌來確認這一點，如果使用外部提供商，它們的值將為 external。AWS 和 OpenStack 驅動的程式碼在 Kubernetes 1.27 版本釋出之前就已經被移除了。除了 AWS、Azure、GCE、OpenStack 和 vSphere 之外的其他提供商從未被包含在 Kubernetes 中，因此它們從一開始就是作為外部雲控制器管理器存在的。

從舊的 Kubernetes 版本升級

如果你正在從低於 1.26 的 Kubernetes 版本升級，並且你正在使用 AWS、Azure、GCE、OpenStack 或 vSphere，那麼你需要啟用 --cloud-provider=external 標誌，並遵循為你的提供商安裝和運行雲控制器管理器的建議。

請閱讀雲控制器管理器管理和遷移複製的控制平面以使用雲控制器管理器的文件。有關特定雲驅動商實現的連結，請參閱下文。

在哪裡可以找到雲控制器管理器？

從本質上講，這則公告是關於以前包含在 Kubernetes 中的雲驅動整合的。隨著這些元件從核心 Kubernetes 程式碼中移出並進入它們自己的倉庫，有幾點需要注意：

首先，SIG Cloud Provider 為希望為任何提供商建立雲控制器管理器的開發人員提供了一個參考框架。有關這些控制器如何工作以及如何開始建立你自己的控制器的更多資訊，請參閱 cloud-provider 倉庫。

其次，有許多可用於 Kubernetes 的雲控制器管理器。本文討論的是歷史上包含在 Kubernetes 中但現在正在被移除的提供商整合。如果你需要為你的提供商找到一個雲控制器管理器但在此處沒有列出，請聯絡你正在整合的雲提供商或 Kubernetes SIG Cloud Provider 社群尋求幫助和建議。值得注意的是，雖然大多數雲控制器管理器如今都是開源的，但這可能並非總是如此。使用者應始終聯絡其雲提供商，以瞭解在其基礎設施上是否有首選的解決方案可供使用。

由 Kubernetes 專案提供的雲驅動整合

如果你正在尋找一種自動化的方法來在你的叢集中安裝雲控制器管理器，kOps 專案為管理生產就緒的叢集提供了一個方便的解決方案。

想了解更多嗎？

雲驅動商和雲控制器管理器在 Kubernetes 中扮演著核心角色。雲驅動商通常是執行 Kubernetes 的基礎，而云控制器管理器則提供了 Kubernetes 叢集與其物理基礎設施之間至關重要的生命線。

本文涵蓋了 Kubernetes 社群與雲基礎設施提供商世界互動的一個方面。如果你對這個話題感到好奇並想了解更多，雲驅動特別興趣小組（SIG）是你的不二之選。SIG Cloud Provider 每兩週舉辦一次會議，討論與 Kubernetes 中的雲驅動商和雲控制器管理器相關的各種話題。

SIG Cloud Provider