2024 年 10 月 16日 – Kubernetes 1.31 版本正式发布，标志着这一开源容器编排平台迈向“真正中立的供应商平台”的重要里程碑。此次更新的核心变化在于彻底移除此前内置的云提供商集成代码，这被 Kubernetes 团队称为“Kubernetes 历史上最大的迁移”。
从“内置”到“外部”：一个时代的结束
过去，Kubernetes 在其核心代码中包含了对 Google Cloud、Microsoft Azure、Amazon Web Services（AWS）、OpenStack 和 VMware vSphere 等五家云提供商的支持。这种“内置”的集成方式虽然在一定程度上简化了用户的使用体验，但也带来了几个弊端：
- 破坏中立性： 内置的云提供商代码使 Kubernetes 无法真正做到供应商中立，限制了用户在不同云平台之间的选择。
- 代码臃肿： 内置的云提供商代码增加了 Kubernetes 代码库的复杂度，也增加了维护和更新的难度。
- 安全风险： 内置的云提供商代码更容易受到安全漏洞的攻击，给用户带来潜在的安全风险。
KEP-2395：迈向中立的决心
早在 2018 年底，一项名为 KEP-2395 的增强提案就提出移除内置的云提供商代码，旨在将 Kubernetes 打造成一个真正中立的平台。该提案指出，用户需要将 CCM（云控制器管理器）部署到他们的集群中，以实现对云提供商的支持。
迁移的挑战与成果
此次迁移工作并非易事。Kubernetes 团队需要对多个组件进行调整，并构建新的子系统来支持 CCM、API服务器网络代理、kubelet 凭据提供程序和存储迁移。据团队称，迁移工作共删除了约 150 万行代码，并将核心组件的二进制大小减少了约 40%。
未来展望：混合部署与更智能的工具
随着 Kubernetes 1.31 的发布，云提供商 SIG 正在探索下一步发展方向。一些建议包括：
- 更智能的混合部署： 允许用户在私有云和公共云上运行节点，以满足不同的需求。
- 更好的工具和框架： 为开发云提供商代码的人们提供更完善的工具和框架，以简化开发流程。
对 DevOps 团队的影响
理论上，此次更改不会给 DevOps 团队带来太大问题，因为 Kubernetes 1.29 版本已经默认中止运行传统内置云提供商，并提供覆盖选项。此外，OpenStack 和 AWS 的内置提供程序已在之前的版本中被移除，因此部署在这些平台上的组织已经进行了必要的更改。
总结：一个新的时代
Kubernetes 1.31 的发布标志着 Kubernetes 迈向真正中立的供应商平台的重要一步。此次迁移不仅提高了 Kubernetes 的灵活性、安全性，也为未来发展奠定了坚实的基础。相信随着 Kubernetes 的不断发展，它将更好地服务于云原生应用的构建和部署，推动云原生技术的不断进步。
Views: 0