Kubernetes 中云提供商的未来

大约 9 个月前，Kubernetes 社区同意成立云提供商特别兴趣小组 (SIG)。其理由是建立一个统一的管理 SIG，负责管理和塑造 Kubernetes 与其支持的众多云提供商之间的集成点。此后发生了很多事情，我们在这里与您分享迄今为止所取得的成就以及我们希望在未来看到的情况。

使命

首先，我想分享 SIG 的使命是什么，因为我们用它来指导我们现在和未来的工作。从我们的 章程 中直接摘录，SIG 的使命是简化、开发和维护云提供商集成，使其作为 Kubernetes 集群的扩展或附加组件。这背后的动机有两个：确保 Kubernetes 保持可扩展性和云无关性。

云提供商的现状

为了对我们的工作有一个前瞻性的视角，我认为退一步审视一下云提供商的现状非常重要。如今，每个核心 Kubernetes 组件（除了调度器和 kube-proxy）都有一个 --cloud-provider 标志，您可以通过配置来启用一组与底层基础设施提供商（又名云提供商）集成的功能。启用此集成可为您的集群解锁各种功能，例如：节点地址和区域发现、用于 Type=LoadBalancer 服务的云负载均衡器、IP 地址管理以及通过 VPC 路由表的集群网络。目前，云提供商集成可以在内部或外部完成。

内部和外部提供商

内部云提供商是我们开发和发布在 主 Kubernetes 存储库 中的提供商。这导致将每个云提供商的知识和上下文嵌入到大多数 Kubernetes 组件中。这实现了更原生的集成，例如 kubelet 通过来自云提供商的元数据服务请求关于自身的信息。

外部云提供商是可以独立于 Kubernetes 核心开发、构建和发布的提供商。这需要部署一个名为 cloud-controller-manager 的新组件，该组件负责运行先前在 kube-controller-manager 中运行的所有云特定控制器。

当最初开发云提供商集成时，它们是原生开发的（内部）。我们将每个提供商集成到 Kubernetes 的核心附近，并集成到如今的 k8s.io/kubernetes 这个单体存储库中。随着 Kubernetes 变得越来越普及，并且越来越多的基础设施提供商希望原生支持 Kubernetes，我们意识到这种模式将无法扩展。每个提供商都带来大量依赖项，这增加了我们代码库中潜在的漏洞，并显著增加了每个组件的二进制文件大小。除此之外，越来越多的 Kubernetes 发行说明开始关注提供商特定的更改，而不是影响所有 Kubernetes 用户的核心更改。

在 2017 年底，我们开发了一种让云提供商构建集成而无需将它们添加到主 Kubernetes 树（外部）的方法。这成为生态系统中新的基础设施提供商与 Kubernetes 集成的实际方法。从那时起，我们一直在积极努力将所有云提供商迁移到使用外部架构，因为如今大多数集群仍然使用内部云提供商。

展望未来

展望未来，SIG 的目标是删除所有现有的内部云提供商，转而支持其外部对等项，并最大限度地减少对用户的影响。除了上述核心云提供商集成之外，还有更多的云集成扩展点，例如 CSI 和镜像凭据提供程序，这些扩展点正在为 v1.15 积极开发中。达到这一点意味着 Kubernetes 真正与云无关，并且没有任何云提供商的本机集成。通过完成这项工作，我们使每个云提供商能够以自己的节奏独立于 Kubernetes 开发和发布新版本。我们现在已经了解到，这是一项艰巨的任务，具有一系列独特的挑战。迁移工作负载从来都不是一件容易的事，尤其是在它是控制平面不可或缺的一部分时。在即将发布的版本中，为内部和外部云提供商之间提供安全且简单的迁移路径是我们 SIG 的首要任务。如果这些内容中的任何一项让您感兴趣，我鼓励您查看我们的一些 KEP，并通过加入 邮件列表 或我们的 slack 频道（Kubernetes slack 中的 #sig-cloud-provider）与我们的 SIG 联系。

• ←上一篇
下一篇→