这篇文章发表时间超过一年。较旧的文章可能包含过时的内容。请检查页面信息自发布以来是否仍是正确的。

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 版本中移除。

发生了什么变化？

最基本的层面是，有两个 Feature Gate 的默认值从 false 变为 true。这些 Feature Gate，DisableCloudProviders 和 DisableKubeletCloudCredentialProviders，控制着 kube-apiserver、kube-controller-manager 和 kubelet 这些组件中调用与云提供商相关代码的方式。当这些 Feature Gate 为 true（默认值）时，--cloud-provider 命令行参数的唯一可识别值为 external。

让我们看看 官方 Kubernetes 文档 对这些 Feature Gate 的描述：

DisableCloudProviders: 禁用 kube-apiserver、kube-controller-manager 和 kubelet 中与 --cloud-provider 组件标志相关的任何功能。

DisableKubeletCloudCredentialProviders: 禁用 kubelet 中用于向云提供商容器镜像仓库进行身份验证以获取镜像拉取凭证的内置功能。

Beta 之后的下一阶段将是完全移除；从该版本开始，你将无法再将这些 Feature Gate 覆盖回 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 Gate。为此，将以下命令行标志添加到先前列出的命令参数中：

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

请注意，如果您在命令行中还有其他 Feature Gate 修改，它们需要包含这两个 Feature Gate。

注意：这些 Feature Gate 将在即将发布的版本中锁定为 true。将这些 Feature Gate 设置为 false 应作为最后的手段使用。强烈建议迁移到外部云控制器管理器，因为内置提供商计划最早在 Kubernetes 1.31 版本中移除。

在其他提供商上升级

对于 Azure、GCE 或 vSphere 以外的提供商，好消息是外部云控制器管理器应该已经在使用了。您可以通过检查集群中 kubelet 的 --cloud-provider 标志来确认这一点，如果使用外部提供商，它们的值将是 external。AWS 和 OpenStack 提供商的代码已在 1.27 版本发布前从 Kubernetes 中移除。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