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 中用于向云提供商容器注册表进行身份验证以获取映像拉取凭据的树内功能。

除了测试版之外的下一阶段将是完全删除；从该版本开始，您将无法将这些功能门覆盖回 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。在 1.27 版本发布之前，AWS 和 OpenStack 提供商的代码已从 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