多集群亲和性组配置

在 PropagationPolicy 中，用户可通过 ClusterAffinities 字段声明多个集群组。调度器会按照组在 spec 中的顺序逐组评估：

• 若某组不满足调度约束，该组内所有集群将被忽略（除非这些集群也属于后续其他组，即一个集群可属于多个组）
• 若所有组均不满足约束，则调度失败（不会选择任何集群）

重要说明：

1. 互斥规则：ClusterAffinities 与 ClusterAffinity 不可同时使用
2. 缺省行为：若两者均未设置，所有集群均可作为调度候选

典型用例

场景1：混合云优先级调度

• 主组（优先）：本地数据中心的私有集群
• 次组（备用）：云服务商提供的托管集群
  调度逻辑：

1. 优先尝试将工作负载调度到主组
2. 仅当主组不满足约束（如资源不足）时，才考虑次组

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: multi-group-demo
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinities:
      - affinityName: local-clusters  # 主组（优先）
        clusterNames: 
          - private-cluster-1
          - private-cluster-2
        # 可叠加其他约束（如标签选择器）
        clusterSelector:
          matchLabels:
            location: on-premise
      - affinityName: cloud-clusters  # 次组（备用）
        clusterNames:
          - huawei-cluster-1
          - aws-cluster-1
        clusterSelector:
          matchLabels:
            provider: [huaweicloud, aws]

在灾难恢复场景中，集群可以被组织为主集群和备集群组，工作负载首先会被调度到主集群。当主集群发生故障（例如数据中心停电）时，Karmada 调度器可以将工作负载迁移到备集群。

基于污点和容忍的调度

.spec.placement.clusterTolerations 字段在 PropagationPolicy 中表示容忍（Tolerations）。与 Kubernetes 一样，容忍必须与集群上的污点（Taints）一起使用。为集群设置一个或多个污点后，除非策略明确声明这些污点是容忍的，否则工作负载不能被调度到这些集群或在这些集群上运行。目前，Karmada 支持的污点效果包括 NoSchedule 和 NoExecute。

karmadactl taint 来设置集群的污点：

# 使用键为 'dedicated'、值为 'special-user'、效果为 'NoSchedule' 的污点更新集群 'foo'
# 如果已有相同键和效果的污点，则会按指定替换其值
karmadactl taint clusters foo dedicated=special-user:NoSchedule

# 如果集群 'foo' 中存在键为 'dedicated'、效果为 'NoSchedule' 的污点，则将其移除
karmadactl taint clusters foo dedicated:NoSchedule-

# 移除集群 'foo' 中所有键为 'dedicated' 的污点
karmadactl taint clusters foo dedicated-

# 向集群 'foo' 添加一个键为 'bar' 且没有值的污点，效果为 'NoSchedule'
karmadactl taint clusters foo bar:NoSchedule

查看污点信息

root@test-k8s-master1:~/istio-demo/karmada/nginx# kubecmd get cluster  kind-test -o yaml|grep -C 5 taint
      name: memory
  secretRef:
    name: kind-test
    namespace: karmada-cluster
  syncMode: Push
  taints:
  - effect: NoSchedule
    key: dedicated
    value: special-user
status:
  apiEnablements:
root@test-k8s-master1:~/istio-demo/karmada/nginx# 

为了将工作负载调度到上述集群，你需要在策略中声明以下内容：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  #...
  placement:
    clusterTolerations:
    - key: dedicated
      value: special-user
      Effect: NoSchedule

多区域高可用性支持

代码

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  placement:
    replicaScheduling:
      replicaSchedulingType: Duplicated
    spreadConstraints:
      - spreadByField: region
        maxGroups: 2
        minGroups: 2
      - spreadByField: cluster
        maxGroups: 1
        minGroups: 1

• 这段代码定义了一个Karmada的传播策略(PropagationPolicy)，用于控制工作负载在多个集群中的分布方式。下面我将详细分析这个配置及其备注的含义。
• 表示副本调度类型为"完全复制"模式
• 在这种模式下，工作负载会在所有选定的集群上完整部署，每个集群都有完整的副本数
• 与"Divided"（分割）模式相对，后者会将副本数分配到不同集群

2. spreadConstraints 分布约束

配置了两级分布约束：

第一级：按区域(region)分布

- spreadByField: region
  maxGroups: 2
  minGroups: 2

• 要求工作负载分布在2个不同的区域（不多不少正好2个）
• 确保跨区域的高可用性

第二级：按集群(cluster)分布

- spreadByField: cluster
  maxGroups: 1
  minGroups: 1

• 在每个区域内，只选择1个集群（不多不少正好1个）
• 与区域约束结合，最终效果是在2个不同区域各选1个集群，共2个集群部署

备注的重要说明

1. 与StaticWeightList的互斥性：
2. 如果replicaScheduling使用StaticWeightList（静态权重列表）策略，那么spreadConstraints的声明将被忽略
3. 这是因为静态权重已经明确指定了副本分配方式，不允许自动的分布约束
4. SpreadByFieldCluster的必要性：
5. 当使用任何SpreadByField（如SpreadByFieldRegion）时，必须同时包含SpreadByFieldCluster
6. 例如，当按区域分组时，必须同时指定每个区域内要选择的集群数量
7. 这是为了确保分布策略的完整性和明确性

实际效果

这个配置的实际效果是：

1. 从所有可用集群中，选择2个不同区域（region）
2. 在每个选定的区域中，各选择1个集群
3. 最后在选定的2个集群上完整部署工作负载（Duplicated模式）
4. 实现了跨区域的高可用部署，同时避免了同一区域内多个集群的冗余部署

案列：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: nginx-propagation
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx-test-v1
  placement:
    clusterAffinity:
      clusterNames:
        - kind-test
        - kind-my-cluster
    replicaScheduling:
      replicaSchedulingType: Duplicated
    spreadConstraints:
      - spreadByField: region   #这里是按region分布
        maxGroups: 2       #最多选择两个region
        minGroups: 2
      - spreadByField: cluster #这里按集群分布
        maxGroups: 1 #每个region最多选择1个cluster
        minGroups: 1 #每个region最少选择1个cluster

分发策略 优先级配置概述

策略优先级概述

当PropagationPolicy和ClusterPropagationPolicy同时匹配工作负载时，Karmada将优先选择PropagationPolicy。若多个PropagationPolicy匹配同一工作负载，系统将按照优先级规则进行选择。优先级分为显式优先级和隐式优先级两种。

显式优先级配置

在PropagationPolicy中，spec.priority字段表示显式优先级，数值越大优先级越高。
注意：未指定时默认为0。

# 高优先级策略 (priority=2)
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: propagation-high-explicit-priority
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      labelSelector:
        matchLabels:
          app: nginx
  priority: 2  # 显式优先级
  placement:
    clusterAffinity:
      clusterNames:
        - member1

# 低优先级策略 (priority=1)
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: propagation-low-explicit-priority
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      labelSelector:
        matchLabels:
          app: nginx
  priority: 1
  placement:
    clusterAffinity:
      clusterNames:
        - member2

# 默认优先级策略 (priority=0)
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: propagation-default-priority
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      labelSelector:
        matchLabels:
          app: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member3

结果：nginx Deployment将被分发到member1集群（最高显式优先级）。

隐式优先级规则

spec.resourceSelectors决定了隐式优先级，从低到高排序如下：

1. 名称(name)和标签选择器(labelSelector)均为空的策略
2. 仅标签选择器匹配的策略
3. 名称精确匹配的策略

# 空匹配策略 (最低隐式优先级)
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: propagation-emptymatch
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
  placement:
    clusterAffinity:
      clusterNames:
        - member1

# 标签选择器匹配策略
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: propagation-labelselectormatch
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      labelSelector:
        matchLabels:
          app: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member2

# 名称精确匹配策略 (最高隐式优先级)
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: propagation-namematch
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: nginx
  placement:
    clusterAffinity:
      clusterNames:
        - member3

结果：nginx Deployment将被分发到member3集群（名称精确匹配具有最高隐式优先级）。

相同优先级处理规则

显式优先级相同情况

当多个策略显式优先级相同时，系统将选择隐式优先级更高的策略。

完全同优先级情况

当显式和隐式优先级都相同时，按策略名称字母序升序选择。

暂停与恢复资源分发

PropagationPolicy 和 ClusterPropagationPolicy 中的 .spec.suspension 字段允许对一个或多个集群的资源分发进行暂停和恢

暂停与恢复资源分发

PropagationPolicy 和 ClusterPropagationPolicy 中的 .spec.suspension 字段允许对一个或多个集群的资源分发进行暂停和恢复。

暂停向所有集群分发资源

为了暂停向所有成员集群分发资源，您可以使用以下配置：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
 name: nginx-propagation
spec:
 #...
 placement:
  clusterAffinity:
   exclude:
    - member1
    - member3
  #...
  suspension:
    dispatching: true

在 Karmada 控制平面上对 nginx Deployment 的更新将不会被同步到任何成员集群。

暂停向特定集群分发资源

为了暂停向个别的成员集群分发资源，您可以在
.spec.suspension.clusterNames 字段中指定集群名称：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
 name: nginx-propagation
spec:
 #...
 placement:
  clusterAffinity:
   exclude:
    - member1
    - member3
  #...
  suspension:
   dispatchingOnClusters:
    clusterNames:
     - member3 # 修改此处的集群名称

在 Karmada 控制平面上对 nginx Deployment 的更新将不会被同步到 member3 集群，但会被同步到所有其他集群。

恢复资源分发

为了恢复资源工作，您只需移除 .spec.suspension 配置：

apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
 name: nginx-propagation
spec:
 #...
 placement:
  clusterAffinity:
   exclude:
    - member1
    - member3
  #...

Karmada 控制平面中的 nginx Deployment 状态将被同步到所有成员集群，任何后续的更新也将被同步。