新发布的 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 的云控制器循环。”
云控制器管理器的角色——不再是可选的
向新版迁移的复杂性来源于“众多受影响的组件和依赖于内置集成的关键代码路径”，云提供商 SIG（特别兴趣小组）今年早些时候解释说，用户要做的工作包括必须从头开始构建“四个新的子系统”，涵盖 CCM、API 服务器网络代理、kubelet 凭据提供程序和存储迁移。
kubelet 是一个在 Kubernetes 集群的每个 VM（虚拟机）或节点上运行的代理。
据该团队称，迁移工作取得了显著成果，“删除了大约 150 万行代码，并将核心组件的二进制大小减少了约 40%。”
云提供商 SIG 就是为这次迁移而成立的，并且已经为此工作了好几年，现在它正在研究下一步该做什么。一些建议包括更智能的混合部署——节点可以在私有云和公共云上运行——以及为开发云提供商代码的人们提供“更好的工具和框架”。
理论上，这一更改不会给 DevOps 团队带来问题，因为它已经被很好地标记过了。Kubernetes 1.29 于 2023 年 12 月首次发布，如果启用了传统的内置云提供商，该版本默认情况下会中止运行，但这个设置可被覆盖。此外，OpenStack 的内置提供程序在 1.26 中被删除，AWS 的内置提供程序在 Kubernetes 1.27 中被删除，因此在这些平台和版本上部署的组织已经进行了必要的更改。
声明：本文由 InfoQ 翻译，未经许可禁止转载。