1. 多集群背景

  随着以Kubernetes为核心的云原生技术的日益普及，用户拥有的Kubernetes集群的数量也呈现爆发式的增长，海量集群的管理和应用的分发，给企业带来了不同程度的问题。

1.1 集群数量快速增长的原因

造成集群数量快速增长，其本质原因分为以下几类。

1）单集群规模受限

根据kubernetes官方大规模集群注意事项，以1.24版本为例，Kubernetes集群规模自限如下

• 节点数不宜超过5000
• 每个节点的Pod数量不超过110个
• Pod总数不超过150000
• 容器总数不超过300000

2）服务跨集群容灾

将服务部署在单个大集群中，容灾能力较差，集群管理面组件异常时，服务恢复和故障转移等难度比较大。通过多集群部署，可以实现跨集群的资源同步、服务发现、以及同城双活等能力。

3）多云、混合云场景需求愈发旺盛

企业出于各方面都考虑，也越来悦青睐于使用多云、混合云架构，其初衷如下，

• 出于成本考量，采购多云（多个公有云服务）以降低财务风险，达到控费 
• 业务差异导向，有的业务适合跑在AI、GPU集群
• 减少厂商依赖
• 提高规模、异地容灾

1.2 集群数量过多造成的影响

1）数据和资源无法共享

集群之间的业务相关性很弱，数据、资源和流量互相独立，会导致一系列问题，导致云原生应用的落地效果受到不同程度的影响：

• 单个集群的资源瓶颈导致云原生应用的弹性能力受限
• 单个集群的爆炸半径无法得到有效控制导致云原生应用的故障恢复能力不足
• 数据（data gravity)和资源的割裂导致云原生应用呈"有状态"

2）资源管理成本较高，企业运维平台需要面临不同的云厂商的管理差异、集群访问API差异等

3）业务分散割裂、业务在集群之间需要差异化配置以适应不同的云厂商、各个集群间应用的统一发布和升级不易。

2. 多集群管理平台及其历程

2.1 业界的多集群管理平台

  基于以上种种原因，国外各大主流云厂商率先打造自家的多集群解决方案，如Google的Anthos、RedHad的Advanced Cluster Management、VMware的Tanzu等。正如当年容器编排领域的百家争鸣，最终由Kubernetes以完全开放、厂商中立的方式结束一样，相信多集群管理领域也会出现一款开源的、厂商中立的标准产品。

  在开源领域，有Rancher的Fleet和Garender，但是Fleet主要面向以Gitops为核心的领域，定位有点局限，而Garender侧重于集群本身的管理，在应用编排和调度维度并没有涉及。当前来看，Kubernetes社区的Fedration项目被给予很大的希望。

2.2 开源社区多集群项目历程

2015年，社区成立了SIG-Federation兴趣小组，后改名为SIG-Multicluster小组，开发并开源了Federation项目，该阶段主要是原型验证阶段(POC), 不具备生产能力，该方案有诸多缺点，如将集群的信息嵌入原生K8s API的annotation中，导致原生API非常臃肿、没有集群声明周期管理的API，其对集群生命周期管理无法扩展、无法提供API对象版本控制。

2017年， Fedration V2开始研发, 并改名KubeFed，该阶段因为产品设计存在一些问题，也并没得到业界的认可，主要问题在于引入了新的API，有一定的学习成本，这种不兼容原生K8s API的设计方式，极大的挑战了用户的使用习惯，用户（K8s的直接用户基本都是开发者）习惯于使用原生的K8s API，其Paas平台的构建，都是基于原生K8s API实现的，如要兼容Kubefed，改动成本会非常高，平台所有的API都要重新适配；

2020年， Fedration V3开始研发, 并正式改名Karmada，目前看在开源社区影响力, 并且已经成为CNCF孵化项目, 部分友商的多集群管理平台也是基于Karmada实现的；

2021年，社区开源了Clusternet项目，该项目是直接对标Fedration V3也就是Karmada。

 

3. 多集群管理方案调研

3.1 Federation V3（Karmada）

Karmada是基于Federation V1、v2的基础上演化而来的，其架构核心组件及功能如下，

• ETCD：存储Karmada API对象。
• Karmada API Server：提供与其他组件进行通信的 REST 接口，包含Kubernetes原生API及Karmada扩展API
• Karmada Scheduler：提供高级的多集群调度策略，包括区域，可用区，云提供商，集群亲和性/反亲和性等调度策略
• Karmada Controller Manager: 包含多个Controller，Controller监听karmada对象并且与成员集群API server进行通信。主要的controller有
• Cluster Controller：负责管理集群的生命周期

   2）Policy Controller： 负责监听PropagationPolicy对象，创建ResourceBinding对象

   3）Binding Controller：负责监听2）中创建的ResourceBinding对象，并为相应的子集群创建Work对象

   4）Execution Controller：负责监听3）中创建的Work对象，将资源分发到对应的子集群

缺点：

• 组件繁多, 开发、运维、部署有一定的复杂性，需要维护额外的etcd服务
• 中心式操作和管理Kubernetes集群，随时集群规模的不断膨胀，对Karmada控制面的操作压力会比较大

3.2 Open Cluster Management (OCM)

社区开源的多集群管理方案，采用类似Kubernetes的Master-Agent架构，在OCM中，将跳出过去KubeFed V2那种中心化，命令式的架构。

包含两个主要概念

• Hub Cluster: 表示运行着OCM多集群控制平面的集群。通常hub cluster应该是一个轻量级的Kubernetes集群，仅仅托管着一些基础的控制器和服务。
• Klusterlet: 表示由hub cluster管理着的集群，也被称为“managed cluster”或“spoke cluster”。klusterlet应该主动的从hub cluster 拉取 最新的处方，并持续将物理的Kubernetes集群调和到预期状态。

在集群的注册过程中，采用了“双重握手”的机制，也就是Hub集群先初始化之后，需要经历Agent集群向Hub发起注册、Hub集群显示接受两个过程，并且目前只支持命令行多方式，其过程如下所示：

# Initialize the hub
clusteradm init

# Request a managed cluster to join the hub
clusteradm join --hub-token <token> --hub-apiserver <api server url> --cluster-name <cluster name>

# Accept the managed cluster request on the hub
clusteradm accept --clusters <list of clusters> # clusteradm accept --clusters c1,c2,...

缺点：

集群注册的流程比较严格，双重握手机制不利于用户操作，而且项目目前处于初级阶段，部分友商基于kubevela + ocm实现的多集群管理功能。

3.3 Clusternet

基于Hub-agent模式构建，兼具多集群管理和跨集群应用编排的功能，完全复用已有的 Kubernetes 集群及端口，通过 AA （Aggregated APIServer[1]） 的方式进行工作，方便灵活扩展，大大减轻运维复杂度和资源消耗。

其架构轻量化和精简化，只有clusternet-hub和cluster-agent两个组件。

1）clusternet-hub 

组件 clusternet-hub 部署和运行在父集群中，通过 AA （Aggregated APIServer）的方式进行工作。

主要负责：

• 批准各个子集群的注册请求，并为其创建专属的资源，如命名空间（namespace）、服务帐户（ServiceAccount）和 RBAC 规则等。
• 维护父集群跟各个子集群的长链接。
• 提供 Kubernetes 风格 的 REST API 用于访问各个子集群，尤其是对于边缘子集群的访问，同时还支持子集群的服务互访。
• 支持多集群的应用分发及治理。

2）clusternet-agent 

组件 clusternet-agent 部署在各个子集群中。

主要负责：

• 将当前集群自动注册到父集群中作为子集群。
• 建立与父集群的 TCP 全双工的 websocket 安全隧道。支持通过 FeatureGate “SocketConnection” 选择是否要建立安全隧道。如果关闭该特性的话，即意味着父集群可以通过直连的方式访问子集群。
• 上报集群的心跳信息，包括 Kubernetes 版本、平台信息healthz/readyz/livez 健康状态、集群容量、节点状态等。

基于 Clusternet 轻量和灵活的架构，支持父集群自注册，Clusternet-hub 可向自身所在集群发布应用，该种方式最大化的利用父集群资源，并可以快速地扩展用户现有的集群，轻松具备管理海量公有云、私有云、边缘云集群的能力。

3.4 小结

Federation方案做的比较重，需要部署单独的ETCD服务，其开发、应用、部署的工程量比较大；OCM项目虽然是CNCF Sandbox项目，但是其热度一般，主集群和子集群之间的认证流程冗余，不利于平台集成；Clusternet架构精简，采用Hub-Agent模式，支持便捷的集群接入、多集群管理和资源调度，并且对用户而言没有学习成本，都是原生的K8s资源，其缺点是对于服务网格能力的兼容目前是完全缺失的，结合CCE当前的状态，采用社区Clusternet方案即可，如果涉及到istio的集成，目前karmada已经实现。