Kubernetes云供应商架构的将来

首先，我想分享SIG的使命，由于咱们用它来指导咱们如今和未来的工做。从咱们的章程中直接来看，SIG的使命是简化，开发和维护云供应商集成，做为Kubernetes集群的扩展或附加组件。这背后的动机是双重的：确保Kubernetes保持可扩展性和云中立（agnostic）。

云供应商的现状

为了得到前瞻性的工做视角，我认为从新审视云供应商的当前状态很是重要。今天，每一个核心Kubernetes组件（除了调度程序和kube-proxy）都有一个-cloud-provider标志，你能够配置该标志以启用一组与底层基础架构提供程序集成的功能，即云供应商程序。启用此集成可为群集启用一系列功能，例如：节点地址和区域发现，具备Type= LoadBalancer的服务的云负载平衡器，IP地址管理以及经过VPC路由表的群集网络。今天，云供应商集成能够在树中或在树外完成。

In-Tree和Out-of-Tree供应商

树内云提供程序是咱们在主Kubernetes存储库中开发和发布的供应商程序。这致使将每一个云供应商的知识和上下文嵌入到大多数Kubernetes组件中。这使得更多原生集成（例如，kubelet）可以经过来自云供应商的元数据服务来请求关于其自身的信息。

In-Tree Cloud Provider Architecture

树外云供应商是能够独立于Kubernetes核心开发，构建和发布的供应商。这须要部署一个名为cloud-controller-manager的新组件，该组件负责运行之前在kube-controller-manager中运行的全部特定于云的控制器。

Out-of-Tree云供应商架构

当最初开发云提供程序集成时，它们是原生开发的（在树中）。咱们将每一个供应商集成在Kubernetes的核心附近，并在今天的k8s.io/kubernetes总体存储库中。随着Kubernetes变得愈来愈广泛，愈来愈多的基础设施供应商但愿原生支持Kubernetes，咱们意识到这种模式不会扩展。每一个提供程序都会带来大量依赖项，这会增长代码库中的潜在漏洞，并显着增长每一个组件的二进制大小。除此以外，更多Kubernetes发行说明开始关注供应商特定的更改，而不是影响全部Kubernetes用户的核心更改。

在2017年底，咱们为云供应商开发了一种方法来构建集成，而无需将它们添加到主Kubernetes树（树外）。这成为生态系统中新的基础设施供应商与Kubernetes集成的事实上的方式。从那时起，咱们一直在积极努力迁移全部云供应商以使用树外架构，由于现在大多数集群仍在使用树内云供应商。

展望将来

展望将来，SIG的目标是删除全部现有的树内云供应商，转而使用树外的实现，同时对用户的影响最小。除了上面提到的核心云供应商集成以外，还有更多的云集成扩展点，如CSI和镜像凭据供应商，正在为v1.15积极开展工做。达到这一点意味着Kubernetes真正与云中立，没有针对任何云供应商的原生集成。经过这项工做，咱们使每一个云供应商可以独立于Kubernetes以本身的节奏开发和发布新版本。咱们如今已经知道，这是一项具备独特挑战的巨大壮举。迁移工做负载绝非易事，尤为是当它是控制平面的重要组成部分时。在即将发布的版本中，咱们的SIG最优先考虑在树内和树外云供应商之间提供安全且简便的迁移路径。若是你对此感兴趣，我建议你查看咱们的一些KEP并经过加入邮件列表或咱们的Slack渠道（Kubernetesslack中的#sig-cloud-provider）与咱们的SIG取得联系。