3. 跨集群调度核心概念:调度策略、资源抽象、拓扑分布约束、集群亲和性与反亲和性

在跨集群调度场景中,调度器不再仅管理单个 Kubernetes 集群内的 Pod 放置,而是需要在一个由多个集群组成的联邦或舰队(Fleet)中做出全局最优决策。理解其核心概念是构建安全、高效、合规的跨集群基础设施的基石。本节将深入剖析调度策略、资源抽象、拓扑分布约束以及集群亲和性与反亲和性这四个关键支柱。

3.1 调度策略:从“调度”到“放置”的范式转变

传统单集群调度器(如 kube-scheduler)关注的是“将 Pod 调度到哪个 Node”。跨集群调度器(如 Karmada、Clusternet、Federation v2)关注的是“将 Workload 放置到哪个 Cluster”。这种转变带来了全新的策略模型。

维度 单集群调度 (Node) 跨集群调度 (Cluster)
调度单元 Pod Workload (Deployment, StatefulSet, etc.)
决策依据 Node 资源、污点、亲和性 集群资源、集群标签、地域、成本、合规
核心策略 LeastRequestedPriority, BinPacking DynamicWeight, StaticWeight, 最低负载, 地域优先
再调度 基于 Node 故障或资源压力 基于集群健康、全局负载均衡、策略变更
关键策略模式:
  • 静态权重策略 (Static Weight): 管理员为每个集群分配固定权重,调度器按权重比例分发副本。适用于已知固定容量的集群。
  • 动态权重策略 (Dynamic Weight): 调度器实时采集集群的剩余 CPU、内存、GPU 等资源,按可用资源比例动态调整分发权重。适用于资源使用率波动大的场景。
  • 最低负载策略 (Least Loaded): 优先将新 Workload 放置到当前资源利用率最低的集群,以实现全局负载均衡。
  • 地域优先策略 (Geo-Affinity): 根据用户请求的来源地域,将 Workload 调度到最近的集群,以降低延迟。

3.2 资源抽象:跨集群资源统一视图

跨集群调度器需要屏蔽底层集群的异构性,提供统一的资源抽象。这通常通过“资源模板”和“资源分发”机制实现。

跨集群资源抽象模型 统一资源模板 (ResourceTemplate) 调度策略引擎 (Scheduling Policy Engine) 集群 A (AWS us-east-1) 集群 B (GCP us-central1) 集群 C (On-Prem) 资源抽象将 Workload 定义与集群绑定解耦,调度器根据策略将模板实例化到目标集群。 每个集群接收到的资源对象是经过策略裁剪后的“分发版本”。
实践要点: 资源抽象层必须支持 Overrides(覆盖)机制。例如,集群 A 使用 gp2 存储类,集群 B 使用 pd-ssd,调度器在分发 Deployment 时,应能自动替换 storageClassName 字段,而无需修改原始模板。

3.3 拓扑分布约束:精细化控制副本分布

拓扑分布约束(Topology Spread Constraints)在跨集群场景中升级为“集群级拓扑”。它允许用户定义 Workload 的副本在多个集群之间如何分布,以满足高可用、容灾或成本优化需求。

apiVersion: scheduling.karmada.io/v1alpha1
kind: PropagationPolicy
metadata:
  name: web-app-spread
spec:
  resourceSelectors:
    - apiVersion: apps/v1
      kind: Deployment
      name: web-app
  placement:
    clusterTolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "production"
      effect: "NoSchedule"
    clusterAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        clusterSelector:
          matchExpressions:
          - key: "region"
            operator: "In"
            values:
            - "us-east"
            - "eu-west"
    topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: "kubernetes.io/region"
      whenUnsatisfiable: "DoNotSchedule"
    replicas: 6
参数 说明 跨集群场景下的含义
topologyKey 拓扑域键 通常使用集群标签,如 kubernetes.io/region、kubernetes.io/zone、provider
maxSkew 最大倾斜度 任意两个拓扑域之间副本数的最大差值。值为 1 表示完全均匀分布
whenUnsatisfiable 不满足时的行为 DoNotSchedule(严格约束)或 ScheduleAnyway(尽力而为)
安全审计关注点: 拓扑分布约束可能被恶意利用来绕过合规策略。例如,一个 Workload 被配置为 maxSkew: 0 且 topologyKey: "compliance-level",如果某个集群的 compliance-level 标签被篡改,可能导致敏感数据被调度到非合规集群。OPA 策略应审计 topologySpreadConstraints 的配置,确保其与数据分类策略一致。

3.4 集群亲和性与反亲和性:智能放置与故障隔离

集群亲和性(Cluster Affinity)和反亲和性(Cluster Anti-Affinity)是跨集群调度中最强大的约束机制,用于表达 Workload 与集群特征之间的“偏好”或“必须”关系。

集群亲和性与反亲和性决策流程 Workload 定义 集群亲和性/反亲和性评估 required / preferred 规则匹配 匹配集群列表 排除集群列表 表达式示例 亲和性: clusterSelector.matchExpressions[ {key: "environment", operator: "In", values: ["prod"]} ] 反亲和性: 通过 clusterSelector 的 NotIn/DoesNotExist 实现,或使用独立的 AntiAffinity 字段 典型场景: 将支付服务调度到 PCI-DSS 合规集群,将 AI 训练任务调度到 GPU 集群
集群亲和性 vs 反亲和性:
  • 集群亲和性 (Cluster Affinity): 吸引 Workload 到特定集群。例如:“将所有需要 GPU 的 Pod 调度到带有 gpu=true 标签的集群”。
  • 集群反亲和性 (Cluster Anti-Affinity): 排斥 Workload 离开特定集群。例如:“将 Workload A 和 Workload B 的副本分散到不同集群,避免单点故障”。
  • 强制 vs 偏好: requiredDuringSchedulingIgnoredDuringExecution 是硬约束,调度器必须满足;preferredDuringSchedulingIgnoredDuringExecution 是软约束,调度器会尽力满足但不会阻塞调度。
DevSecOps 集成建议: 在 CI/CD 管道的“变更门禁”阶段,使用 OPA 策略验证 PropagationPolicy 中的 clusterAffinity 和 clusterAntiAffinity 规则。例如,确保生产环境的 Workload 必须具有 requiredDuringSchedulingIgnoredDuringExecution 的亲和性规则,且目标集群必须属于“生产”环境标签组。这可以防止因配置错误导致 Workload 被调度到开发或测试集群。