本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。

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