📚 课程目录第3章跨集群调度核心概念

3. 跨集群调度核心概念：调度器扩展机制、拓扑分布约束与亲和性

跨集群调度是云原生多集群管理的核心挑战。Kubernetes 原生调度器提供了丰富的扩展点，使得运维人员能够根据业务需求定制调度策略。本章深入剖析调度器扩展机制（Scheduler Extender / Pluggable Scheduler）、拓扑分布约束（Topology Spread Constraints）以及节点亲和性与 Pod 反亲和性，为后续的变更门禁安全审计奠定理论基础。

3.1 调度器扩展机制

Kubernetes 调度器是一个可扩展的组件，允许通过两种主要方式注入自定义调度逻辑：Scheduler Extender（调度器扩展器）和 Pluggable Scheduler（可插拔调度器）。

特性	Scheduler Extender	Pluggable Scheduler
架构	作为 HTTP(S) 外部服务，被原生调度器回调	完全独立的调度器二进制，替换默认调度器
扩展点	Filter、Prioritize、Bind、Preempt	调度框架（Scheduling Framework）的所有扩展点
部署复杂度	低，无需替换调度器	高，需维护独立调度器
灵活性	受限于回调接口	完全控制调度逻辑
跨集群适用性	适合轻量级策略注入	适合复杂多集群调度算法

  安全审计要点： 使用 Scheduler Extender 时，必须对 Extender 的 HTTPS 端点进行证书验证和访问控制，防止恶意调度请求注入。Pluggable Scheduler 需确保其镜像来源可信，并定期审计其调度策略配置。

3.2 拓扑分布约束

拓扑分布约束（Topology Spread Constraints）是 Kubernetes 1.19+ 引入的调度特性，用于控制 Pod 在集群内不同拓扑域（如节点、可用区、地域）的分布均匀性。在跨集群场景中，拓扑分布约束可以扩展到集群级别，实现跨集群的 Pod 均匀分布。

核心参数

maxSkew：最大偏斜度，控制任意两个拓扑域之间 Pod 数量的最大差值。
topologyKey：拓扑域标签键，如 kubernetes.io/hostname、topology.kubernetes.io/zone、topology.kubernetes.io/cluster。
whenUnsatisfiable：不满足约束时的行为，可选 DoNotSchedule（不调度）或 ScheduleAnyway（尽量调度）。
labelSelector：用于匹配 Pod 的标签选择器。

跨集群实践： 在跨集群调度中，将 topologyKey 设置为自定义的集群标签（如 cluster-name），可以实现 Pod 在多个集群间的均匀分布，避免单集群过载。

配置示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cross-cluster-app
spec:
  replicas: 6
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/cluster
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: cross-cluster-app
      containers:
        - name: app
          image: myapp:latest

3.3 节点亲和性与 Pod 反亲和性

亲和性规则是 Kubernetes 调度中控制 Pod 放置位置的核心机制。在跨集群调度中，它们被用于实现精细化的调度策略。

类型	子类型	描述	跨集群应用
节点亲和性	requiredDuringSchedulingIgnoredDuringExecution	硬性要求，必须满足才能调度	强制 Pod 调度到特定集群或节点池
	preferredDuringSchedulingIgnoredDuringExecution	软性偏好，尽量满足	优先调度到低负载集群
Pod 反亲和性	requiredDuringSchedulingIgnoredDuringExecution	硬性要求，Pod 不能与某些 Pod 同拓扑域	确保关键服务跨集群分散部署
	preferredDuringSchedulingIgnoredDuringExecution	软性偏好，尽量分散	优化资源利用率，避免单点故障

安全审计风险： 亲和性规则配置不当可能导致调度死锁或资源碎片。审计时应检查是否存在冲突的亲和性规则，以及是否设置了合理的 topologyKey 范围，防止 Pod 被“锁定”在特定集群而无法迁移。

3.4 三种机制的协同与安全审计

在实际跨集群调度中，调度器扩展机制、拓扑分布约束和亲和性规则需要协同工作，以实现高效、安全的调度策略。安全审计应关注以下关键点：

调度器扩展点审计：检查 Extender 或 Pluggable Scheduler 的代码和配置，确保没有后门或恶意逻辑。
拓扑约束验证：确认 maxSkew 和 topologyKey 配置合理，避免因约束过严导致 Pod 无法调度。
亲和性规则冲突检测：使用工具（如 kube-score）检测节点亲和性与 Pod 反亲和性之间的潜在冲突。
跨集群标签一致性：确保所有集群的拓扑标签（如 cluster-name）命名规范且一致，防止调度错乱。
变更门禁集成：在 Helm Chart 的变更门禁中，加入调度策略的静态检查，阻止不符合安全策略的调度配置。

  审计清单示例：
  是否所有 Scheduler Extender 端点都启用了 TLS 和认证？
拓扑分布约束的 whenUnsatisfiable 是否设置为 DoNotSchedule 以防止意外调度？
节点亲和性规则是否使用了 requiredDuringScheduling 导致调度死锁？
Pod 反亲和性是否设置了合理的 topologyKey 范围（如集群级别而非节点级别）？