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

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集群，对上述的事情也在积极探索中。期待更多的讨论和交流，也欢迎感兴趣的同学加入我们一起探索。

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