本文发布已超过一年。较旧的文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不准确。
Kubernetes 中 Cloud Providers 的未来
大约 9 个月前，Kubernetes 社区同意组建 Cloud Provider 特殊兴趣小组 (SIG)。这样做的理由是希望有一个统一的 SIG 来负责和规划 Kubernetes 与其支持的众多云提供商之间的集成点。自那时以来，许多工作一直在进行中，我们在这里与你分享迄今为止取得的成就以及我们希望在未来看到的情况。
使命
首先，我想分享一下 SIG 的使命，因为我们用它来指导我们现在和未来的工作。直接摘自我们的章程，SIG 的使命是简化、开发和维护作为 Kubernetes 集群扩展或附加组件的云提供商集成。这背后的动机有两方面：确保 Kubernetes 保持可扩展性并保持云无关性。
Cloud Providers 的现状
为了对我们的工作有一个前瞻性的视角，我认为重要的是回顾一下云提供商的现状。如今，每个核心 Kubernetes 组件（除了调度器和 kube-proxy）都有一个 --cloud-provider 标志，你可以配置它来启用一组与底层基础设施提供商（即云提供商）集成的功能。启用此集成将为你的集群解锁一系列广泛的特性，例如：节点地址和区域发现、用于 Services 的云负载均衡器（Type=LoadBalancer 类型）、IP 地址管理以及通过 VPC 路由表实现的集群网络。目前，云提供商集成可以在 In-tree 或 Out-of-tree 中完成。
In-Tree 和 Out-of-Tree 提供商
In-tree 云提供商是我们在主 Kubernetes 仓库中开发和发布的提供商。这导致将每个云提供商的知识和上下文嵌入到大多数 Kubernetes 组件中。这使得更原生的集成成为可能，例如 kubelet 通过云提供商的元数据服务请求自身信息。
In-Tree 云提供商架构（来源：kubernetes.io）
Out-of-tree 云提供商是可以独立于 Kubernetes 核心进行开发、构建和发布的提供商。这需要部署一个名为 cloud-controller-manager 的新组件，该组件负责运行所有先前在 kube-controller-manager 中运行的特定于云的控制器。
Out-of-Tree 云提供商架构（来源：kubernetes.io）
当云提供商集成最初开发时，它们是原生（in-tree）开发的。我们将每个提供商紧密集成到 Kubernetes 的核心，并集成到如今的 k8s.io/kubernetes 这个单一仓库中。随着 Kubernetes 变得越来越普及，以及越来越多的基础设施提供商希望原生支持 Kubernetes，我们意识到这种模式无法扩展。每个提供商都会带来大量的依赖，这增加了我们代码库中潜在的漏洞，并显著增加了每个组件的二进制大小。此外，更多的 Kubernetes 发布说明开始关注特定于提供商的变更，而不是影响所有 Kubernetes 用户的核心变更。
在 2017 年末，我们开发了一种方法，允许云提供商构建集成，而无需将其添加到主 Kubernetes 树中（out-of-tree）。这成为生态系统中新基础设施提供商与 Kubernetes 集成的实际方式。自那时以来，我们一直积极努力将所有云提供商迁移到使用 out-of-tree 架构，因为今天大多数集群仍然使用 in-tree 云提供商。
展望未来
展望未来，SIG 的目标是删除所有现有的 in-tree 云提供商，转而支持其 out-of-tree 等效项，同时尽量减少对用户的影响。除了上述核心云提供商集成之外，还有更多云集成扩展点，如 CSI 和 image credential provider，这些在 v1.15 中正在积极开发。达到这一点意味着 Kubernetes 真正实现云无关性，没有任何云提供商的原生集成。通过这项工作，我们使每个云提供商能够按照自己的节奏独立于 Kubernetes 进行开发和发布新版本。我们现在已经认识到，这是一项艰巨的任务，伴随着一系列独特的挑战。迁移工作负载从来都不容易，尤其当它是控制平面的重要组成部分时。在未来的版本中，为 in-tree 和 out-of-tree 云提供商之间提供安全简便的迁移路径是我们的 SIG 的最高优先级。如果这些内容对你感兴趣，我鼓励你查看我们的一些KEPs，并通过加入邮件列表或我们的 Slack 频道（Kubernetes Slack 中的 #sig-cloud-provider）与我们的 SIG 联系。