K8s多集群实践，随着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 ，这与云原生社区的发展理念是相悖。
2.Federation v2：
已经被社区废弃，提供了一个可以将任何 K8s API type 转换成有多集群概念的 federated type 的方法，以及一个对应的控制器以便推送这些 federated 对象 (Object)。而它并不像 V1 一样关心复杂的推送策略（V1 的 Federation Scheduler），只负责把这些 Object 分发到用户事先定义的集群去。这也就意味着 Federation v2 的主要设计目标，其实是向多集群推送 RBAC，policy 等集群配置信息。
3.Karmada：
参考Kubernetes Federation v2 核心实践，并融入了众多新技术，包括 Kubernetes 原生 API 支持、多层级高可用部署、多集群自动故障迁移、多集群应用自动伸缩、多集群服务发现等，并且提供原生 Kubernetes 平滑演进路径。
4.Clusternet：
是一个兼具多集群管理和跨集群应用编排的开源云原生管控平台，解决了跨云、跨地域、跨可用区的集群管理问题。在项目规划阶段，就是面向未来混合云、分布式云和边缘计算等场景来设计的，支持海量集群的接入和管理、应用分发、流量治理等。
5.OCM：
OCM 是一款 Kubernetes 多集群平台开源项目，它可以帮助你大大简化跨云/多云场景下的集群管理，无论这些集群是在云上托管，还是部署在自建数据中心，再或者是在边缘数据中心中。OCM 提供的基础模型可以帮助我们同时理解单集群内部的容量情况，也可以横跨多集群进行资源/工作负载的编排调度。与此同时，OCM 还提供了一系列强大的扩展性或者叫做插件框架（addon-framework）来帮助我们集成 CNCF 生态中的其他项目，这些扩展性也可以帮助我们无侵入地针对你的特定使用场景手工扩展特性。
以上多集群项目主要功能为资源分发和调度，还有如多云基础设施管理cluster-api，多集群检索Clusterpedia，多集群pod互通submariner，multicluster-ingress解决多集群的ingress，服务治理和流量调度 Service Mesh，如istio、cilium等网络组件实现的multi cluster mesh解决跨集群的mesh网络管理，以及结合存储相关项目实现跨集群存储管理和迁移等。
2.2 vivo 在多集群上的探索
2.2.1 非联邦集群管理