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


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

查看所有标签

猜你喜欢:

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

三双鞋

三双鞋

[美] 谢家华 / [美] 谢传刚 / 中华工商联合出版社 / 2011-1 / 32.90元

本书是“美捷步”(Zappos)首席执行官谢家华创造奇迹的心路历程与商业哲学的精华萃取,分享了他在商场与生活中得到的宝贵经验与教训。从儿时创办蚯蚓养殖场到大学经营比萨生意,从“链接交换”公司到“美捷步”品牌,本书将谢家华的个人传记与其公司传奇的商业史完美结合,不仅打造了一套利润、激情和目标渐次递进的独特商业模式,更揭示了成功路上起决定作用的真正秘密:奉上幸福。一起来看看 《三双鞋》 这本书的介绍吧!

MD5 加密
MD5 加密

MD5 加密工具

正则表达式在线测试
正则表达式在线测试

正则表达式在线测试

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具