完成 Kubernetes 历史上最大规模的迁移

作者：Andrew Sy Kim (Google), Michelle Au (Google), Walter Fender (Google), Michael McCune (Red Hat) | 2024 年 5 月 20 日星期一

早在 Kubernetes v1.7 版本，Kubernetes 项目就一直追求一个雄心勃勃的目标：移除内置的云提供商集成（KEP-2395）。尽管这些集成在 Kubernetes 的早期开发和发展中起到了重要作用，但移除它们的动机主要有两个关键因素：在数百万行 Go 代码中维护对所有云提供商的原生支持日益复杂，以及建立 Kubernetes 作为真正供应商中立平台的愿望。

经过多个版本迭代，我们激动地宣布，所有云提供商集成已成功从 Kubernetes 核心仓库迁移到外部插件。除了实现我们的初步目标外，我们还通过移除大约 150 万行代码并将核心组件的二进制文件大小减少约 40%，显著精简了 Kubernetes。

由于受影响的组件众多，并且依赖于最初五个云提供商（Google Cloud、AWS、Azure、OpenStack 和 vSphere）的内置集成的关键代码路径，本次迁移是一项复杂且耗时的工作。为了成功完成本次迁移，我们不得不从零开始构建了四个新的子系统

Cloud Controller Manager (KEP-2392)
API Server 网络代理 (KEP-1281)
Kubelet 凭据提供者插件 (KEP-2133)
存储迁移以使用 CSI (KEP-625)

每个子系统对于实现与内置功能的完整功能对等至关重要，并且需要多个版本才能使每个子系统达到 GA 级别成熟度，并提供安全可靠的迁移路径。下面将详细介绍每个子系统。

Cloud Controller Manager

Cloud Controller Manager 是本次工作中引入的第一个外部组件，取代了 kube-controller-manager 和 kubelet 中直接与云 API 交互的功能。这个关键组件负责通过应用元数据标签来初始化节点，这些标签指示节点所在的云区域和可用区，以及仅云提供商知道的 IP 地址。此外，它还运行 Service Controller，负责为 LoadBalancer 类型的 Service 供应云负载均衡器。

Kubernetes components

要了解更多信息，请阅读 Kubernetes 文档中的Cloud Controller Manager。

API Server 网络代理

API Server 网络代理项目于 2018 年启动，是与 SIG API Machinery 合作的成果，旨在取代 kube-apiserver 中的 SSH 隧道功能。该隧道曾用于在 Kubernetes 控制平面和节点之间安全地代理流量，但它高度依赖于嵌入在 kube-apiserver 中特定于提供商的实现细节来建立这些 SSH 隧道。

现在，API Server 网络代理是 kube-apiserver 中的一个 GA 级别扩展点。它提供了一种通用的代理机制，可以通过安全代理将流量从 API Server 路由到节点，从而无需 API Server 了解其运行在哪个特定的云提供商上。该项目还引入了 Konnectivity 项目，该项目在生产环境中已得到越来越多的采用。

您可以从其README 中了解更多关于 API Server 网络代理的信息。

kubelet 的凭据提供者插件

开发 Kubelet 凭据提供者插件是为了取代 kubelet 内置的动态获取托管在 Google Cloud、AWS 或 Azure 上的镜像仓库凭据的功能。这项旧功能很方便，它允许 kubelet 无缝地检索短期令牌以从 GCR、ECR 或 ACR 拉取镜像。然而，就像 Kubernetes 的其他领域一样，支持此功能需要 kubelet 具备关于不同云环境和 API 的特定知识。

凭据提供者插件机制于 2019 年引入，为 kubelet 提供了一个通用扩展点，用于执行可动态为托管在各种云上的镜像提供凭据的插件二进制文件。这种可扩展性扩展了 kubelet 获取短期令牌的能力，使其不仅限于最初的三个云提供商。

要了解更多信息，请阅读用于认证镜像拉取的 Kubelet 凭据提供者。

存储插件从 in-tree 迁移到 CSI

容器存储接口 (CSI) 是一个控制平面标准，用于在 Kubernetes 和其他容器编排器中管理块存储和文件存储系统，该标准在 1.13 版本中达到 GA 级别。它旨在取代直接内置于 Kubernetes 中的 in-tree 卷插件，改用可以在 Kubernetes 集群内作为 Pod 运行的驱动程序。这些驱动程序通过 Kubernetes API 与 kube-controller-manager 存储控制器通信，并通过本地 gRPC 端点与 kubelet 通信。现在，所有主要云和存储供应商都提供了 100 多个 CSI 驱动程序，使 Kubernetes 中的有状态工作负载成为现实。

然而，一个主要挑战是如何处理所有使用 in-tree 卷 API 的现有用户。为了保持 API 向后兼容性，我们在控制器中构建了一个 API 转换层，将 in-tree 卷 API 转换为等效的 CSI API。这使得我们可以将所有存储操作重定向到 CSI 驱动程序，为我们在不移除 API 的情况下移除内置卷插件的代码铺平了道路。

您可以在Kubernetes In-Tree 到 CSI 卷迁移进入 Beta 中了解更多关于 In-tree 存储迁移的信息。

下一步是什么？

在过去几年中，本次迁移一直是 SIG Cloud Provider 的主要重点。随着这一重要里程碑的实现，我们将把精力转向探索 Kubernetes 与云提供商更好地集成的新方法和创新方式，利用我们多年来构建的外部子系统。这包括使 Kubernetes 在混合环境中更加智能，其中集群中的节点可以在公共云和私有云上运行，并为外部提供商的开发者提供更好的工具和框架，以简化和优化他们的集成工作。

随着所有新功能、工具和框架的规划，SIG Cloud Provider 没有忘记等式的另一边：测试。该 SIG 未来活动的另一个重点是改进云控制器测试以包含更多提供商。这项工作的最终目标是创建一个包含尽可能多提供商的测试框架，以便我们为 Kubernetes 社区提供对其 Kubernetes 环境的最高级别的信心。

如果您使用的 Kubernetes 版本低于 v1.29 并且尚未迁移到外部云提供商，我们建议您查阅我们之前的博文Kubernetes 1.29: 云提供商集成现在是独立组件了。它提供了我们所做更改的详细信息，并提供了如何迁移到外部提供商的指导。从 v1.31 版本开始，in-tree 云提供商将被永久禁用并从 Kubernetes 核心组件中移除。

如果您有兴趣做出贡献，欢迎加入我们每两周一次的 SIG 会议！