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 资源抽象:跨集群资源统一视图
跨集群调度器需要屏蔽底层集群的异构性,提供统一的资源抽象。这通常通过“资源模板”和“资源分发”机制实现。
实践要点: 资源抽象层必须支持 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 与集群特征之间的“偏好”或“必须”关系。
集群亲和性 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 被调度到开发或测试集群。