本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
完成 Kubernetes 历史上最大规模的迁移
早在 Kubernetes v1.7 时，Kubernetes 项目就设定了移除内置云驱动集成的宏伟目标 (KEP-2395)。尽管这些集成在 Kubernetes 早期发展和壮大过程中起到了关键作用，但移除它们主要出于两个关键因素：一是在数百万行 Go 代码中为每个云厂商维护原生支持的复杂性日益增加；二是希望将 Kubernetes 打造为一个真正厂商中立的平台。
经过多个版本的努力，我们激动地宣布，所有云驱动集成已成功从 Kubernetes 核心仓库迁移到外部插件。除了实现我们的初步目标外，我们还通过移除约 150 万行代码，并将核心组件的二进制文件大小减少约 40%，显著精简了 Kubernetes。
这次迁移是一项复杂而长期的工作，因为它涉及众多组件和关键代码路径，这些都依赖于最初五个云厂商（Google Cloud、AWS、Azure、OpenStack 和 vSphere）的内置集成。为了成功完成这次迁移，我们必须从头构建四个新的子系统：
每个子系统对于实现与内置功能完全对等都至关重要，并且需要经过数个版本的迭代，才能使每个子系统达到生产就绪（GA）级别的成熟度，并提供安全可靠的迁移路径。以下是每个子系统的详细介绍。
云控制器管理器
云控制器管理器是这项工作中引入的第一个外部组件，取代了 kube-controller-manager 和 kubelet 中直接与云 API 交互的功能。这个关键组件负责初始化节点，通过应用元数据标签来表明节点所在的云区域和可用区，以及只有云厂商才知道的 IP 地址。此外，它还运行服务控制器，负责为 LoadBalancer 类型的服务提供云负载均衡器。
要了解更多信息，请阅读 Kubernetes 文档中的云控制器管理器。
API 服务器网络代理
API 服务器网络代理项目于 2018 年与 SIG API Machinery 合作启动，旨在取代 kube-apiserver 中的 SSH 隧道功能。该隧道曾用于安全地代理 Kubernetes 控制平面和节点之间的流量，但它严重依赖于嵌入在 kube-apiserver 中的厂商特定的实现细节来建立这些 SSH 隧道。
现在，API 服务器网络代理是 kube-apiserver 中一个达到生产就绪（GA）级别的扩展点。它提供了一个通用的代理机制，可以通过一个安全的代理将流量从 API 服务器路由到节点，从而消除了 API 服务器需要了解其运行在哪家特定云厂商上的需求。该项目还引入了 Konnectivity 项目，该项目在生产环境中的采用率越来越高。
你可以从其 README 中了解更多关于 API 服务器网络代理的信息。
Kubelet 的凭证提供程序插件
Kubelet 凭证提供程序插件的开发是为了取代 kubelet 内置的动态获取托管在 Google Cloud、AWS 或 Azure 上的镜像仓库凭证的功能。旧的功能很方便，因为它允许 kubelet 无缝地检索用于从 GCR、ECR 或 ACR 拉取镜像的短期令牌。然而，与 Kubernetes 的其他领域一样，支持这项功能需要 kubelet 具备对不同云环境和 API 的特定了解。
凭证提供程序插件机制于 2019 年引入，为 kubelet 提供了一个通用的扩展点，可以执行插件二进制文件，动态地为托管在各种云上的镜像提供凭证。这种可扩展性将 kubelet 获取短期令牌的能力扩展到了最初的三家云厂商之外。
要了解更多信息，请阅读用于认证镜像拉取的 kubelet 凭证提供程序。
存储插件从树内迁移到 CSI
容器存储接口（CSI）是一个用于在 Kubernetes 和其他容器编排器中管理块存储和文件存储系统的控制平面标准，于 1.13 版本达到生产就绪（GA）。它旨在用可以在 Kubernetes 集群内作为 Pod 运行的驱动程序取代直接内置于 Kubernetes 的树内卷插件。这些驱动程序通过 Kubernetes API 与 kube-controller-manager 的存储控制器通信，并通过本地 gRPC 端点与 kubelet 通信。现在，所有主流云和存储供应商都提供了超过 100 种 CSI 驱动程序，使得在 Kubernetes 中运行有状态的工作负载成为现实。
然而，如何处理所有现有的树内卷 API 用户仍然是一个重大挑战。为了保持 API 的向后兼容性，我们在控制器中构建了一个 API 转换层，它将树内卷 API 转换为等效的 CSI API。这使我们能够将所有存储操作重定向到 CSI 驱动程序，为我们移除内置卷插件的代码而不移除 API 铺平了道路。
你可以在Kubernetes 树内卷到 CSI 卷的迁移进入 Beta 阶段中了解更多关于树内存储迁移的信息。
接下来是什么？
这次迁移是 SIG Cloud Provider 过去几年的主要工作重点。随着这一重要里程碑的实现，我们将把精力转向探索新的创新方式，利用我们多年来构建的外部子系统，让 Kubernetes 更好地与云厂商集成。这包括让 Kubernetes 在混合环境中更加智能，其中集群中的节点可以同时运行在公有云和私有云上，以及为外部提供商的开发者提供更好的工具和框架，以简化和 streamlining 他们的集成工作。
随着所有新功能、工具和框架的规划，SIG Cloud Provider 并未忘记问题的另一面：测试。SIG 未来活动的另一个重点是改进云控制器测试，以包含更多的提供商。这项工作的最终目标是创建一个包含尽可能多提供商的测试框架，以便我们为 Kubernetes 社区提供对其 Kubernetes 环境最高水平的信心。
如果你使用的 Kubernetes 版本低于 v1.29 并且尚未迁移到外部云驱动，我们建议你查阅我们之前的博文Kubernetes 1.29：云驱动集成现已分离为独立组件。该文详细介绍了我们所做的更改，并提供了如何迁移到外部驱动的指导。从 v1.31 开始，树内云驱动将被永久禁用并从 Kubernetes 核心组件中移除。
如果你有兴趣贡献，欢迎加入我们每两周一次的 SIG 会议！