Kubernetes的集群联邦之路还有多远?

栏目: IT技术 · 发布时间: 4年前

内容简介:Kubernetes官方声称单集群最多可支持5000个节点和15万个Pod,也有研发能力比较强的公司号称可以把规模做到10000个节点,但我相信很少有公司会部署如此庞大的一个单集群,即使能够运营这么大的集群,总有很多情况下因为各种各样的原因我们仍然需要部署多个集群,例如容灾、隔离、多云或避免厂商锁定或者其他限制性因素。我们不可避免地需要同时部署和运营多个集群,但如果想将我们的应用跨集群部署起来,并不是一件简单的事。有人会提到社区的集群联邦(Federation),如果你深入了解过的可能会发现,Federat

Kubernetes官方声称单集群最多可支持5000个节点和15万个Pod,也有研发能力比较强的公司号称可以把规模做到10000个节点,但我相信很少有公司会部署如此庞大的一个单集群,即使能够运营这么大的集群,总有很多情况下因为各种各样的原因我们仍然需要部署多个集群,例如容灾、隔离、多云或避免厂商锁定或者其他限制性因素。

我们不可避免地需要同时部署和运营多个集群,但如果想将我们的应用跨集群部署起来,并不是一件简单的事。

有人会提到社区的集群联邦(Federation),如果你深入了解过的可能会发现,Federation v1 是“出师未捷身先死“,Federation v2目前还是alpha版本,也是在“难产“之中,想要指望社区提供一套完备的多集群解决方案,我们还需要等待一些时日。之前调研以及和业界的朋友讨论中也发现,这确实是目前业界面临的一个痛点,各大厂几乎都没有一套完备的、行之有效的、可复用的解决方案,公有云应该尤其需要解决这个问题(不知道做公有云的同学如何看待这个问题)。其中,阿里云在使用Federation v2,其他一些厂商不不支持集群联邦。私有云用户也是积极在自己造轮子搞一套解决方案,来解决应用分发到多个集群的问题。

Kubernetes的集群联邦之路还有多远?

图片来源: https://www.researchgate.net/f ... 55698

仔细想想,这听起来还是比较有讽刺性意味的,在大家都觉得Kubernetes已经发展到如此成熟,甚至有些Boring,各个厂商和玩家鼓吹多云化的时候发现:如何简单有效地将多个Kubernetes集群统一利用起来还没有解决。这就要求用户自己去解决,根据不同集群做应用部署的分发和调度。作为用户,还是有点没有被满足的意思。

那么,一个理想中的集群联邦是什么样子呢?

简单的就是一句话:可以跨集群管理应用程序,在满足容灾、隔离等要求下提升资源的使用效率,并像在使用一个集群的用户体验。很明显目前的Federation v2也并不满足这个要求,Kubefed专注于将任意负载类型传播到多个集群,而不是跨集群部署应用程序。

举个例子:

Kubernetes的集群联邦之路还有多远?

跨集群管理应用负载

在此示例中,当我们期望部署StatefulSet负载副本数为10,则最终负载会根据集群大小和限制被跨集群分布在不同的集群中,并且负载的数量之和就是我们定义的数量。

Kubernetes的集群联邦之路还有多远?

Federation v2负载传播

在此示例中,如果使用Federation v2,则每个StatefulSet集群中的每个工作负载将具有10的副本。

想要达到这样的效果,有两件事情是需要我们考虑的:

  • 如何定义跨集群工作负载?
  • 如何分发工作负载到多个集群/可用区/故障域?

如何定义跨集群工作负载?

在单个集群内,可用区的概念并没有在API中体现。而是由一组具有相同位置标签的宿主机表示,例如为宿主机打上idc或zone标签,从而来代表不同的可用区。想要实现分布Pod在多个可用区,需要在调度约束中强制做可用区打散,但需要外部协调控制,很难使用单个部署StatefulSet或Deployment执行可用区感知到Pod的部署。不过在Kubernetes 1.16中,引入了一个称为“ Pod拓扑扩展约束”的新功能。我们现在可以在Pod Spec中添加新的约束,并且调度程序将强制执行这些约束,以便Pod可以以统一的方式分布在多个故障域之上。

但说到底这也只是单个集群内的拓扑扩展,如果把这一拓扑范围扩展呢?在集群注册表API下有着集群的拓扑信息,如果我定义的应用负载包含这部分信息,那就能做到跨集群和跨可用区的分布。想要实现这个目的,只需要定义一种跨集群管理多个同类工作负载的API即可(可参考: UnitedDeploymemt-支持多域工作负载管理 的描述)。

如何分发工作负载到多个集群/可用区/故障域?

在这种情况下,联邦调度器成为了必不可少的组件,联邦调度器需要能够感知多个集群的负载和资源细节,最终整个集群管理可能会成为双层调度。但这并不是坏事情,在我看来这是可以接受的,联邦调度器做的事情可粗可细。

在联邦调度器应用的情况下,我们能做的事情就更多了,例如:

  • 基于当前多集群的资源情况负载均衡
  • 工作负载跨多个集群(厂商),真正解锁集群(厂商),即使单个集群(厂商)出现问题也不会对服务造成影响
  • 更加精细化的资源优化,提升整个集群资源使用效率,降低成本

后记

这里纯粹抛砖引玉下,并没有直接给出解决方案,因为自己也在运营规模很大、数量较多的Kubernetes集群,对上述的事情也在积极探索中。期待更多的讨论和交流,也欢迎感兴趣的同学加入我们一起探索。

原文链接: https://zhuanlan.zhihu.com/p/94090543


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

算法学

算法学

哈雷尔 / 第1版 (2006年2月1日) / 2006年2月1日 / 38.0

本书的意图在于按序学习或研究,而不是作为一个参考。因而按照每章依赖于前面章节的结构组织本书,且流畅易读。第一部分预备知识中的大部分材料对于那些具有程序设计背景的人是熟悉的。无论是否恰当,本书包含了计算机科学家当前感兴趣的研究专题的简明讨论。这本教科书的书后有每章详细参考书目的注记,并通过“后向”指针把教科书中的讨论与相关文献联系起来。目前的版本包含大量习题,以及大约三分之一的题解。可用题解作为教科......一起来看看 《算法学》 这本书的介绍吧!

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具

HEX HSV 转换工具
HEX HSV 转换工具

HEX HSV 互换工具