导读 首先,我想分享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取得联系。

原文来自:https://www.kubernetes.org.cn/5319.html

本文地址:https://www.linuxprobe.com/kubernetes-cloud-vendor.html编辑:向云艳,审核员:逄增宝

Linux命令大全:https://www.linuxcool.com/

Linux系统大全:https://www.linuxdown.com/

红帽认证RHCE考试心得:https://www.rhce.net/