本文主要讲述了一些对于K8s多集群管理的思考，包括为什么需要多集群、多集群的优势以及现有的一些基于Kubernetes衍生出的多集群管理架构实践。

一、为什么需要多集群

随着K8s和云原生技术的快速发展，以及各大厂商在自己的数据中心使用K8s的API进行容器化应用编排和管理，让应用交付本身变得越来越标准化和统一化，并且实现了与底层基础设施的完全解耦，为多集群和混合云提供了一个坚实技术基础。谈到多集群多云的数据中心基础架构，会想到为什么企业需要多集群？

1.单集群容量限制：

集群上限5000个节点和15万个Pod。同时单集群的最大节点数不是一个确定值，其受到集群部署方式和业务使用集群资源的方式的影响。

2.多云混合使用：

避免被单家供应商锁定，不同集群的最新技术规划，或是出于成本等考虑，企业选择了多云架构。

3.业务流量突发：

正常情况下用户使用自己的 IDC 集群提供服务，当应对突发大流量时，迅速将应用扩容到云上集群共同提供服务，需具备公有云 IaaS接入，可以自动扩缩容计算节点，将公有云作为备用资源池。该模式一般针对无状态的服务，可以快速弹性扩展，主要针对使用 CPU、内存较为密集的服务，如搜索、查询、计算等类型的服务。

4.业务高可用：

单集群无法应对网络故障或者数据中心故障导致的服务的不可用。通常主要服务的集群为一个，另一个集群周期性备份。或者一个集群主要负责读写，其他备份集群只读，在主集群所在的云出现问题时可以快速切换到备份集群。该模式可用于数据量较大的存储服务，如部署一个高可用的mysql集群，一个集群负责读写，其他2个集群备份只读，可以自动切换主备。

5.异地多活：

数据是实时同步的，多集群都可以同时读写，这种模式通常针对极其重要的数据，如全局统一的用户账号信息等。

6.地域亲和性：

尽管国内互联网一直在提速，但是出于带宽成本的考量，同一调用链的服务网络距离越近越好。服务的主调和被调部署在同一个地域内能够有效减少带宽成本；并且分而治之的方式让应用服务本区域的业务，也能有效缓解应用服务的压力。

二、多集群探索

2.1 社区在多集群上的探索

当前基于 K8s 多集群项目如下：

1.Federation v1：

已经被社区废弃，主要原因在于 v1 的设计试图在 K8s 之上又构建一层 Federation API，直接屏蔽掉了已经取得广泛共识的 K8s API ，这与云原生社区的发展理念是相悖。