新发布的 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 的这个文档（）和 Azure 的这个文档（）。
kubelet 是一个在 Kubernetes 集群的每个 VM（虚拟机）或节点上运行的代理。
据该团队称，迁移工作取得了显著成果，“删除了大约 150 万行代码，并将核心组件的二进制大小减少了约 40%。”
云提供商 SIG 就是为这次迁移而成立的，并且已经为此工作了好几年，现在它正在研究下一步该做什么。一些建议包括更智能的混合部署——节点可以在私有云和公共云上运行——以及为开发云提供商代码的人们提供“更好的工具和框架”。
理论上，这一更改不会给 DevOps 团队带来问题，因为它已经被很好地标记过了。Kubernetes 1.29 于 2023 年 12 月首次发布，如果启用了传统的内置云提供商，该版本默认情况下会中止运行，但这个设置可被覆盖。此外，OpenStack 的内置提供程序在 1.26 中被删除，AWS 的内置提供程序在 Kubernetes 1.27 中被删除，因此在这些平台和版本上部署的组织已经进行了必要的更改。
不过，新版本 Kubernetes 的推出是一个渐进的过程，在许多情况下，更改是必要的。有关如何迁移的信息，可以浏览这篇官方文章（）。
原文链接：
