Kubernetes 中云提供商的未来

作者: Andrew Sy Kim(VMware),Mike Crute(AWS),Walter Fender(Google)

大约9个月前,Kubernetes社区同意组建云提供商特别兴趣小组(SIG)。理由是只有一个管理SIG来拥有和塑造Kubernetes及其支持的许多云提供商之间的集成点。自那时以来,有许多活动在进行中,我们在这里与您分享到目前为止已取得的成就以及我们希望将来看到的一切。

使命

首先,我想分享SIG的使命,因为我们用它来指导我们现在和将来的工作。直接取自我们 宪章 SIG的任务是简化,开发和维护云提供商集成,作为Kubernetes集群的扩展或附加组件。其背后的动机有两个:确保Kubernetes保持可扩展性并且与云无关。

云提供商的现状

为了对我们的工作有前瞻性的看法,我认为退后一步来查看云提供商的当前状态非常重要。如今,每个核心Kubernetes组件(调度程序和kube-proxy除外)都具有--cloud-provider标志,您可以对其进行配置以启用与基础架构提供商(也称为云提供商)集成的一组功能。启用此集成将为您的群集解锁一系列广泛的功能,例如:节点地址和区域发现,具有Type = LoadBalancer的服务的云负载平衡器,IP地址管理以及通过VPC路由表的群集网络。如今,云提供商集成可以在树内或树外完成。

树内和树外提供程序

树内云提供商是我们在 Kubernetes 主仓库。这导致将每个云提供商的知识和上下文嵌入到大多数Kubernetes组件中。这可以实现更多本地集成,例如kubelet通过来自云提供商的元数据服务请求有关其自身的信息。

树内云提供程序体系结构(来源:kubernetes.io)

树内云提供程序体系结构(来源:kubernetes.io)

树外云提供商是可以独立于Kubernetes核心进行开发,构建和发布的提供商。这需要部署一个名为cloud-controller-manager的新组件,该组件负责运行先前在kube-controller-manager中运行的所有特定于云的控制器。

树外云提供商体系结构(来源:kubernetes.io)

树外云提供商体系结构(来源:kubernetes.io)

最初开发云提供商集成时,它们是本地(在树中)开发的。我们将每个提供商都集成到了Kubernetes的核心附近,并集成到了今天的k8s.io/kubernetes整体存储库中。随着Kubernetes的普及和越来越多的基础架构提供商希望原生支持Kubernetes,我们意识到这种模式将无法扩展。每个提供程序都带来大量依赖关系,这增加了我们代码库中的潜在漏洞,并显着增加了每个组件的二进制大小。除此之外,更多的Kubernetes发行说明开始关注于特定于提供商的更改,而不是影响所有Kubernetes用户的核心更改。

在2017年末,我们为云提供商提供了一种构建集成而不将其添加到主Kubernetes树(树外)中的方法。这已成为生态系统中新的基础架构提供商与Kubernetes集成的事实上的方式。自那时以来,我们一直在积极努力迁移所有云提供商以使用树外架构,因为当今大多数集群仍在使用树内云提供商。

展望未来

放眼未来,SIG的目标是删除所有现有的树内云提供商,以支持其树外等效物,而对用户的影响最小。除了上面提到的核心云提供程序集成之外,v1.15正在积极致力于诸如CSI和映像凭据提供程序之类的云集成的更多扩展点。达到这一点将意味着Kubernetes真正是不可知的,没有任何云提供商的本地集成。通过这项工作,我们使每个云提供商都可以独立于Kubernetes的节奏来开发和发布新版本。到现在为止,我们已经知道这是一项巨大的壮举,面临着一系列独特的挑战。迁移工作负载绝非易事,尤其是当它是控制平面的重要组成部分时。在即将发布的版本中,为我们的SIG优先考虑在树内和树外云提供商之间提供安全,便捷的迁移路径。如果您觉得其中任何一种有趣,我鼓励您检查一下我们的一些 关键绩效指标 并通过加入我们与我们的SIG联系 邮件列表 或我们的松弛频道(在Kubernetes松弛中为#sig-cloud-provider)。