Karmada 资源传播策略适合怎样的多集群治理

Karmada 的资源传播策略解决的不是“把 YAML 再复制几份”，而是把 Kubernetes 资源应该进入哪些成员集群、如何分布以及策略变更如何生效，集中表达成可治理的规则。对只管理一个命名空间的应用，PropagationPolicy 通常更合适；需要跨命名空间统一约束时，再考虑 ClusterPropagationPolicy。

官方地址：https://karmada.io/

运维判断可以按四个问题展开：资源选得准不准、候选集群是否受控、依赖是否一并传播、策略变更是否会同时影响大量工作负载。四个问题都能回答，再把规则交给 Karmada 执行。

先按治理边界选择策略类型

PropagationPolicy 是命名空间范围的策略，资源选择默认落在策略所在命名空间；ClusterPropagationPolicy 则适合集群级统一规则。两者的 spec 结构相近，但权限和影响范围不同，不能因为字段相似就把所有规则都写成集群级策略。

值班时可以先做一个保守判断：单个团队、单个命名空间的应用优先使用 PropagationPolicy；平台团队要给多个命名空间提供默认传播规则时，再使用集群级策略，并为例外情况预留更高优先级的命名空间级策略。

资源选择器决定“哪些东西会被传播”

resourceSelectors 至少要有一个选择器。可以按 API 版本和 Kind 匹配一类资源，也可以继续用名称、标签和命名空间缩小范围。生产规则不建议只写一个宽泛的 Deployment，因为后续新增资源可能被意外纳入传播范围。

# 只把 default 命名空间中名为 web 的 Deployment 交给本策略管理
apiVersion: policy.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: web-propagation
  namespace: default
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: web # 用名称收窄范围，避免把同命名空间的其它 Deployment 一起选中
  placement:
    clusterAffinity:
      clusterNames:
        - member-east # 只表达目标成员集群，不代表已经完成运行验证
        - member-west

上面的规则把“选什么”和“放哪里”分开表达：选择器负责资源边界，placement 负责集群边界。若需要匹配一组应用，可以改用 labelSelector；但标签命名要有平台约定，否则不同团队的同名标签会让策略范围变得难以审计。

用 placement 处理候选集群与副本分布

clusterAffinity 可以直接列出集群名，也可以按集群标签筛选候选集。候选集不等于最终分布：当应用副本或多集群容灾有明确要求时，还要配合 spread constraints 和副本调度策略，避免“写了多个集群名但实际只落在一个集群”。

依赖传播与多策略冲突要单独处理

工作负载常常引用 ConfigMap 或 Secret。启用 propagateDeps: true 后，相关依赖可以随工作负载自动传播，减少重复列出资源的配置量；但这也扩大了传播边界，敏感配置应先确认目标集群、权限和数据驻留要求。

多个策略同时匹配时，显式 priority 更高的策略优先；没有显式优先级时，资源选择器的精确程度也会影响选择。命名空间级 PropagationPolicy 与集群级策略同时命中时，应先按命名空间级规则检查。只有在确实要接管低优先级规则时，才使用 preemption: Always，避免一次配置变更覆盖大量既有资源。

策略变更前的运维检查与回滚边界

默认的激活行为会让策略变化较快影响资源模板。对管理大量工作负载的策略，可以评估 activationPreference: Lazy，把传播变化推迟到资源模板下一次更新；如果只是临时暂停传播，则应使用项目当前版本支持的暂停字段，并在变更单中写清恢复条件。

1. 先列出策略将匹配的 API、Kind、命名空间、名称或标签范围，确认没有把 Secret 等敏感资源一并选中。
2. 再检查成员集群标签、容量和故障域，确认候选集与 spread constraints 的目标一致。
3. 启用依赖传播前，确认 ConfigMap、Secret 的同步权限和跨集群数据边界。
4. 调整优先级或启用抢占前，保留原策略清单，并准备按原版本恢复。
5. 变更后观察 ResourceBinding、Work 和目标集群资源状态；这些是运维核对路径，不应把静态说明图当成运行证据。

一句话总结：Karmada 资源传播策略的核心不是“写一份更复杂的 YAML”，而是把资源选择、集群选择、依赖传播和策略冲突拆成可以审计的边界。边界越窄，故障影响面越容易控制；规则越集中，平台治理越容易复用。

常见问题

PropagationPolicy 和 ClusterPropagationPolicy 应该怎么选？

只服务一个命名空间或团队时优先选择命名空间级策略；需要跨命名空间提供平台默认规则时再考虑集群级策略，并为局部例外保留清晰的优先级关系。

resourceSelectors 为空是不是代表匹配全部资源？

不是。官方 API 说明要求至少提供一个选择器，空选择器不会被当成“所有资源”，这也是避免敏感资源被意外传播的重要边界。

启用 propagateDeps 后还要写 ConfigMap 和 Secret 吗？

被工作负载引用的依赖可以自动传播，但仍应检查依赖关系是否被正确识别，以及目标集群的权限、合规和数据驻留要求是否允许这样做。