Kubernetes 1.31 已正式发布，完成了内置云提供商（in-tree cloud provider）代码的全面移除，被团队称为“Kubernetes历史上最大的一次迁移”。这一升级虽然增强了平台的中立性，但可能会破坏现有脚本，例如现在 kubelet 唯一有效的 cloud-provider 参数为 “external”。

过去，Kubernetes 核心代码支持五大云提供商：Google Cloud、Microsoft Azure、AWS、OpenStack 和 VMware vSphere。虽然这种支持便捷，但破坏了Kubernetes作为供应商中立平台的理念。内置云提供商代码不仅增加了代码体量，也使更新变得困难，同时提高了潜在安全风险。

早在 2018 年末，KEP-2395 提出移除内置云提供商的方案。方案指出，用户需要在集群中部署 Cloud Controller Manager（CCM），而之前用户可通过命令行标志启用 kubernetes-controller-manager 的云控制循环。如今，云提供商也提供了 CCM 部署文档，如针对 AWS 和 Azure 的说明。

此次迁移复杂的原因在于众多受影响组件和依赖内置集成的关键代码路径。Cloud Provider SIG 解释称，他们从零构建了四个新子系统：CCM、API Server 网络代理、kubelet 凭证提供器和存储迁移工具。kubelet 是运行在每个虚拟机或节点上的代理。

迁移成果显著：移除了约150万行代码，核心组件二进制文件体积缩小约40%。Cloud Provider SIG 在完成这一长期任务后，目前正在考虑下一步工作，包括更智能的混合云部署和为云提供商代码开发更完善的工具与框架。

对 DevOps 团队而言，这一变化理论上不会造成问题，因为早有提示。Kubernetes 1.29 已默认在使用旧版内置云提供商时中止运行，虽然可手动覆盖。而 OpenStack 内置提供商在 1.26 版本被移除，AWS 在 1.27 被移除，因此在这些平台上部署的组织大多已完成必要调整。

Kubernetes 新版本的部署通常是渐进式的，因此在实际升级中仍可能需要额外改动。官方迁移指南提供了详细操作步骤，帮助团队顺利完成过渡。

相关文章：

史蒂夫·鲍尔默是一位被低估的CEO 分布式存储排名前十名TOP榜单 MySQL索引在MyISAM和InnoDB存储引擎中的实现区别 MySQL九种高可用方案介绍（自动故障转移+数据可靠性） Spring Cloud 是如何实现灰度发布和蓝绿部署的？在项目中如何用到？ 微软弃用 Polyglot Notebooks，引发用户强烈不满 Spring Cloud Gateway 和 Zuul 有什么区别？为什么建议使用 Gateway？ 为什么有的网站读取 Access 数据库时会出现问题或没有数据？