完成 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 项目，该项目在生产环境中得到了越来越多的采用。
您可以从其 自述文件 中了解有关 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 云提供商的主要关注点。随着这一重要里程碑的实现，我们将把我们的努力转向探索新的创新方法，使 Kubernetes 能够更好地与云提供商集成，从而利用我们多年来构建的外部子系统。这包括使 Kubernetes 在集群中的节点可以在公有云和私有云上运行的混合环境中更加智能，以及为外部提供商的开发人员提供更好的工具和框架，以简化和简化他们的集成工作。
在规划所有新功能、工具和框架的同时，SIG 云提供商并没有忘记等式的另一面：测试。SIG 未来活动的另一个重点领域是改进云控制器测试，以包含更多提供商。此项工作的最终目标是创建一个测试框架，该框架将尽可能多地包含提供商，以便我们为 Kubernetes 社区提供对其 Kubernetes 环境的最高水平的信心。
如果您使用的是低于 v1.29 的 Kubernetes 版本，并且尚未迁移到外部云提供商，我们建议您查看我们之前的博客文章 Kubernetes 1.29：云提供商集成现在是单独的组件。它提供了有关我们所做更改的详细信息，并提供了有关如何迁移到外部提供商的指导。从 v1.31 开始，内部云提供商将被永久禁用并从核心 Kubernetes 组件中删除。
如果您有兴趣参与，请加入我们的双周 SIG 会议！