由于单个集群的限制，有些业务可能需要部署在大量的Kubernetes集群上，此时就需要对多集群进行管理。

首先，将业务部署在单个的大规模集群中是比部署在多个较小集群中危险的，例如单个大集群出现故障，无法进行故障转移。其次，通过联邦集群可以在集群间进行资源同步和跨集群的服务发现，例如同城双活的场景。

• 控制平面组件会因为发生问题，而影响整体集群效率。
• 无法兼容新的 Kubernetes API 资源。
• 无法有效的在多个集群管理权限，如不支持 RBAC。
• 联邦层级的设定与策略依赖 API 资源的 Annotations 内容，这使得弹性不佳

• Host :用于提供 KubeFed API 与控制平面的集群。
• Member :通过 KubeFed API 注册的集群，并提供相关身份凭证来让 KubeFed Controller 能够连接集群。Host 集群也可以作为 Member 被加入。

继V1版本之后，社区又推出了Kubefed V2。相比于kubefed v1， V2有了巨大的改变，例如对 kubernetes 原生资源分发的支持更加灵活，可以支持多个版本的API，弥补了kubefed v1无法兼容新 API 的缺点，另外还支持了 CRD 自身，通过 Placement 字段配置资源分发，通过 Overrides 字段可以差异化配置分发到不同集群的资源。然而 kubefed v2 在推广过程中出现了以下问题：

apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment  #自定义资源类型
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:   #要部署的资源模板
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - image: nginx
            name: nginx
  placement:  # 对象需要部署到集群member1和member2
    clusters:
    - name: member1
    - name: member2
  overrides:  # 修改部署到member2集群的副本数为2
  - clusterName: member2
    clusterOverrides:
    - path: "/spec/replicas"
      value: 2

• 需要通过遍历集群才能获取部署的应用的具体状态，在控制面只能看到应用是否分发成功。

经历了多年发展，联邦集群这个领域的两次尝试都算不上成功。 难道就没有一个更好用的项目用来管理 kubernetes 联邦集群吗？

此时社区中的另一个项目 karmada 初露头角，karmada 继承和改进了kubefed，例如部署 deployment, 在 karmada 中 FederatedDeployment 被拆解成了三个单独的资源，分别是资源模板 resource template 是Kubernetes 原生 API 使用起来更舒服, 调度策略 propagation policy 和差异化配置策略 override policy。

• karmada API server 与 API server 在 Kubernetes 集群中的功能类似，用来处理资源的增删改查及将数据持久到 ETCD 中。
• karmada controller-manager 功能是管理karmada 中的实现的controllers，负责它们的启动和停止等。
• karmada aggregated-api-server 是一个聚合API，该组件实现了通过karmada API server 即可访问成员集群资源的功能，并实现了统一鉴权认证，不用切换 kubeconfig 即可访问不同成员集群。
• karmada Scheduler 实现了 karmada 对资源调度到成员集群的调度功能，并实现了多种调度策略。
• karmada DeScheduler 实现了每隔一段时间就检测一次所有部署，将目标集群中不可调度的副本再调度到其他可调度的集群上。
• karmada scheduler-estimator 用来评估成员集群上可调度的副本数，在一些调度策略中调度器将根据其计算副本数来计算每个目标集群上需要调度的副本数。
• karmada Agent 是部署在成员集群上的组件，用来上报成员集群信息到 karmda 控制平面和从 karmada 控制平面拉取分发到成员集群的资源信息。

karmada 分发资源到成员集群流程如上图所示， 在 karmada 控制平面创建Resource Template 即为kubernetes原生资源，例如 Deployment，Service, configmap 等资源，同时创建 Propagation Policy 资源用来描述分发 Resource Template 到成员集群的策略，例如描述调度到哪些成员集群，使用静态权重策略等，如果有需要同时也可以创建Override Policy用来覆盖分发到不通成员集权中Resource Template中某些字段，例如修改Deployment中的容器镜像地址，容器参数等。

分发策略包含集群级别的 ClusterPropagationPolicy 和 Namespace 级别的PropagationPolicy，集群级别的可以分发各个命名空间的 resource Template，namespace 级别的只能分发自己命名空间级别的 resource Template，用来定义将创建的 resource Templater 分发到成员集群的策略。

Spec.Placement.ClusterAffinity.FieldSelector ：

DynamicWeightByAvailableReplicas 表示应根据可用资源（可用副本）生成集群权重列表。
// Example:
    //   The scheduler selected 3 clusters (A/B/C) and should divide 12 replicas to them.
    //   Workload:
    //     Desired replica: 12
    //   Cluster:
    //     A: Max available replica: 6
    //     B: Max available replica: 12
    //     C: Max available replica: 18
    //   The weight of cluster A:B:C will be 6:12:18 (equals to 1:2:3). At last, the assignment would be 'A: 2, B: 4, C: 6'.

Spec.Placement.ReplicaSchedulingStrategy.WeightPreference.StaticClusterWeight：

OverridePolicy 和 ClusterOverridePolicy 定义下发到不通成员集群中不通配置，karmada支持的有：

• ImageOverrider 覆盖工负载的镜像
• CommandOverrider 覆盖工作负载的 commands
• ArgsOverrider 覆盖工作负载的 args
• PlaintextOverrider 通用工具，覆盖任何种类的资源

ResourceBinding 是由控制器 ResourceDetector 根据 resource Template 和Propagation Policy 的内容自动创建的资源，代表一个 kubernetes 资源和一个分发策略的绑定，与分发策略相对应 ResourceBinding 也分为集群级别的ClusterResourceBinding 和 Namespace 级别的 ResourceBinding，同时也会记录 resource Template 最中部署的状态和结果。具体字段如下：

Spec:

Work

work 定义了部署到目标成员集群的资源列表，由 bingingController 创建或者更新，由 execctionController 进行协调。