内容简介:Kubernetes官方声称单集群最多可支持5000个节点和15万个Pod,也有研发能力比较强的公司号称可以把规模做到10000个节点,但我相信很少有公司会部署如此庞大的一个单集群,即使能够运营这么大的集群,总有很多情况下因为各种各样的原因我们仍然需要部署多个集群,例如容灾、隔离、多云或避免厂商锁定或者其他限制性因素。我们不可避免地需要同时部署和运营多个集群,但如果想将我们的应用跨集群部署起来,并不是一件简单的事。有人会提到社区的集群联邦(Federation),如果你深入了解过的可能会发现,Federat
Kubernetes官方声称单集群最多可支持5000个节点和15万个Pod,也有研发能力比较强的公司号称可以把规模做到10000个节点,但我相信很少有公司会部署如此庞大的一个单集群,即使能够运营这么大的集群,总有很多情况下因为各种各样的原因我们仍然需要部署多个集群,例如容灾、隔离、多云或避免厂商锁定或者其他限制性因素。
我们不可避免地需要同时部署和运营多个集群,但如果想将我们的应用跨集群部署起来,并不是一件简单的事。
有人会提到社区的集群联邦(Federation),如果你深入了解过的可能会发现,Federation v1 是“出师未捷身先死“,Federation v2目前还是alpha版本,也是在“难产“之中,想要指望社区提供一套完备的多集群解决方案,我们还需要等待一些时日。之前调研以及和业界的朋友讨论中也发现,这确实是目前业界面临的一个痛点,各大厂几乎都没有一套完备的、行之有效的、可复用的解决方案,公有云应该尤其需要解决这个问题(不知道做公有云的同学如何看待这个问题)。其中,阿里云在使用Federation v2,其他一些厂商不不支持集群联邦。私有云用户也是积极在自己造轮子搞一套解决方案,来解决应用分发到多个集群的问题。
图片来源: https://www.researchgate.net/f ... 55698
仔细想想,这听起来还是比较有讽刺性意味的,在大家都觉得Kubernetes已经发展到如此成熟,甚至有些Boring,各个厂商和玩家鼓吹多云化的时候发现:如何简单有效地将多个Kubernetes集群统一利用起来还没有解决。这就要求用户自己去解决,根据不同集群做应用部署的分发和调度。作为用户,还是有点没有被满足的意思。
那么,一个理想中的集群联邦是什么样子呢?
简单的就是一句话:可以跨集群管理应用程序,在满足容灾、隔离等要求下提升资源的使用效率,并像在使用一个集群的用户体验。很明显目前的Federation v2也并不满足这个要求,Kubefed专注于将任意负载类型传播到多个集群,而不是跨集群部署应用程序。
举个例子:
跨集群管理应用负载
在此示例中,当我们期望部署StatefulSet负载副本数为10,则最终负载会根据集群大小和限制被跨集群分布在不同的集群中,并且负载的数量之和就是我们定义的数量。
Federation v2负载传播
在此示例中,如果使用Federation v2,则每个StatefulSet集群中的每个工作负载将具有10的副本。
想要达到这样的效果,有两件事情是需要我们考虑的:
- 如何定义跨集群工作负载?
- 如何分发工作负载到多个集群/可用区/故障域?
如何定义跨集群工作负载?
在单个集群内,可用区的概念并没有在API中体现。而是由一组具有相同位置标签的宿主机表示,例如为宿主机打上idc或zone标签,从而来代表不同的可用区。想要实现分布Pod在多个可用区,需要在调度约束中强制做可用区打散,但需要外部协调控制,很难使用单个部署StatefulSet或Deployment执行可用区感知到Pod的部署。不过在Kubernetes 1.16中,引入了一个称为“ Pod拓扑扩展约束”的新功能。我们现在可以在Pod Spec中添加新的约束,并且调度程序将强制执行这些约束,以便Pod可以以统一的方式分布在多个故障域之上。
但说到底这也只是单个集群内的拓扑扩展,如果把这一拓扑范围扩展呢?在集群注册表API下有着集群的拓扑信息,如果我定义的应用负载包含这部分信息,那就能做到跨集群和跨可用区的分布。想要实现这个目的,只需要定义一种跨集群管理多个同类工作负载的API即可(可参考: UnitedDeploymemt-支持多域工作负载管理 的描述)。
如何分发工作负载到多个集群/可用区/故障域?
在这种情况下,联邦调度器成为了必不可少的组件,联邦调度器需要能够感知多个集群的负载和资源细节,最终整个集群管理可能会成为双层调度。但这并不是坏事情,在我看来这是可以接受的,联邦调度器做的事情可粗可细。
在联邦调度器应用的情况下,我们能做的事情就更多了,例如:
- 基于当前多集群的资源情况负载均衡
- 工作负载跨多个集群(厂商),真正解锁集群(厂商),即使单个集群(厂商)出现问题也不会对服务造成影响
- 更加精细化的资源优化,提升整个集群资源使用效率,降低成本
后记
这里纯粹抛砖引玉下,并没有直接给出解决方案,因为自己也在运营规模很大、数量较多的Kubernetes集群,对上述的事情也在积极探索中。期待更多的讨论和交流,也欢迎感兴趣的同学加入我们一起探索。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 中国联邦学习「五大流派」
- Prometheus 联邦及高可用详解
- 腾讯 AngelFL 联邦学习平台揭秘
- 云设计模式之 : 联邦身份模式
- Prometheus学习系列(二十五)之联邦
- 看完这篇,即刻上手进行联邦学习实战
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。