本文发表于一年多前。旧文章可能包含过时内容。请检查页面中的信息自发布以来是否已变得不正确。
Kubernetes 中云驱动的未来
大约 9 个月前，Kubernetes 社区同意成立云提供商特别兴趣小组 (SIG)。这样做的理由是，需要一个统一的 SIG 来负责并塑造 Kubernetes 与其支持的众多云提供商之间的集成点。自那时起，许多工作一直在进行中，我们在此与您分享迄今为止所取得的成就以及我们对未来的展望。
使命
首先，我想分享一下 SIG 的使命，因为我们用它来指导我们现在和未来的工作。直接摘自我们的章程，SIG 的使命是简化、开发和维护云提供商集成，作为 Kubernetes 集群的扩展或附加组件。这背后的动机是双重的：确保 Kubernetes 保持可扩展性和云无关性。
云提供商的现状
为了对我们的工作有一个前瞻性的视角，我认为退一步审视云提供商的现状非常重要。如今，每个核心 Kubernetes 组件（调度器和 kube-proxy 除外）都有一个 --cloud-provider 标志，您可以配置该标志以启用一组功能，这些功能与底层基础设施提供商（即云提供商）集成。启用此集成将为您的集群解锁一系列广泛的功能，例如：节点地址和区域发现、用于 Type=LoadBalancer 的服务的云负载均衡器、IP 地址管理以及通过 VPC 路由表进行的集群网络。目前，云提供商集成可以通过树内或树外方式完成。
树内和树外提供商
树内云提供商是我们开发并发布在主 Kubernetes 仓库中的提供商。这导致将每个云提供商的知识和上下文嵌入到大多数 Kubernetes 组件中。这实现了更原生的集成，例如 kubelet 通过云提供商的元数据服务请求自身信息。
树内云提供商架构（来源：kubernetes.io）
树外云提供商是可以独立于 Kubernetes 核心进行开发、构建和发布的提供商。这需要部署一个名为 cloud-controller-manager 的新组件，它负责运行以前在 kube-controller-manager 中运行的所有特定于云的控制器。
树外云提供商架构（来源：kubernetes.io）
最初开发云提供商集成时，它们是原生（树内）开发的。我们将每个提供商紧密集成到 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 取得联系。