移除了内置的云提供商代码后，Kubernetes 1.31 现在成为了“真正中立的供应商平台”

新发布的 Kubernetes 1.31 已完全移除了此前内置的云提供商集成代码，团队成员将其描述为“Kubernetes 历史上最大的迁移”。但升级到新版可能会破坏现有脚本，例如，kubelet 唯一能用的云提供商参数现在变成了“外部的”。

过去，Kubernetes 在其核心代码（“in-tree”）中包含了对五家云提供商的支持：Google Cloud、Microsoft Azure、Amazon Web Services（AWS）、OpenStack 和 VMware vSphere。虽然这种做法提供了便利，但它破坏了 Kubernetes 作为供应商中立平台的理念。这些提供商的加入也使代码更加臃肿，并且由于提供商代码是内置的，因此更新起来更加困难，还增加了出现安全问题的可能性。

2018 年末，一项增强提案 KEP-2395 要求移除这些内置的云提供商。但该提案指出，“Kubernetes 用户需要将 CCM（云控制器管理器）部署添加到他们的集群中。以前，用户可以通过命令行标志启用 kubernetes-controller-manager 的云控制器循环。”

云控制器管理器的角色——不再是可选的

云提供商现在提供了文档来支持用户部署他们的 CCM，例如 AWS 的这个文档（https://github.com/kubernetes/cloud-provider-aws/blob/master/docs/getting_started.md）和 Azure 的这个文档（https://cloud-provider-azure.sigs.k8s.io/install/azure-ccm/）。

向新版迁移的复杂性来源于“众多受影响的组件和依赖于内置集成的关键代码路径”，云提供商 SIG（特别兴趣小组）今年早些时候解释说，用户要做的工作包括必须从头开始构建“四个新的子系统”，涵盖 CCM、API 服务器网络代理、kubelet 凭据提供程序和存储迁移。

kubelet 是一个在 Kubernetes 集群的每个 VM（虚拟机）或节点上运行的代理。

据该团队称，迁移工作取得了显著成果，“删除了大约 150 万行代码，并将核心组件的二进制大小减少了约 40%。”

云提供商 SIG 就是为这次迁移而成立的，并且已经为此工作了好几年，现在它正在研究下一步该做什么。一些建议包括更智能的混合部署——节点可以在私有云和公共云上运行——以及为开发云提供商代码的人们提供“更好的工具和框架”。

理论上，这一更改不会给 DevOps 团队带来问题，因为它已经被很好地标记过了。Kubernetes 1.29 于 2023 年 12 月首次发布，如果启用了传统的内置云提供商，该版本默认情况下会中止运行，但这个设置可被覆盖。此外，OpenStack 的内置提供程序在 1.26 中被删除，AWS 的内置提供程序在 Kubernetes 1.27 中被删除，因此在这些平台和版本上部署的组织已经进行了必要的更改。

不过，新版本 Kubernetes 的推出是一个渐进的过程，在许多情况下，更改是必要的。有关如何迁移的信息，可以浏览这篇官方文章（https://kubernetes.io/blog/2023/12/14/cloud-provider-integration-changes/）。

原文链接：https://devclass.com/2024/10/01/kubernetes-1-31-now-a-truly-vendor-neutral-platform-thanks-to-removal-of-built-in-cloud-provider-code/