云供应商的现状
为了获得前瞻性的工作视角，我认为重新审视云供应商的当前状态非常重要。今天，每个核心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集成的事实上的方式。从那时起，我们一直在积极努力迁移所有云供应商以使用树外架构，因为如今大多数集群仍在使用树内云供应商。