2. 跨集群调度基础：Kubernetes原生调度器局限、跨集群调度的核心挑战
在单集群环境中，Kubernetes 原生调度器（kube-scheduler）通过一系列预选（Predicates）和优选（Priorities）算法，为 Pod 找到最合适的 Node。然而，当管理规模扩展到多集群时，原生调度器的设计边界决定了它无法直接处理跨集群的调度决策。理解这些局限与核心挑战，是构建版本漂移校准机制的前提。
2.1 Kubernetes原生调度器的三大局限
原生调度器假设所有资源都在同一个 API Server 和同一组 Node 之下。这种“单集群视野”在多集群场景中暴露出以下结构性缺陷：
| 局限维度 | 具体表现 | 对多集群的影响 |
|---|---|---|
| 单集群视野 | 调度器只监听本地集群的 Node 和 Pod 状态，无法感知其他集群的资源水位。 | 无法将 Pod 调度到资源更充裕的远端集群，导致局部过载而全局空闲。 |
| 扁平网络假设 | 默认认为所有 Node 之间二层/三层可达，Pod IP 跨 Node 可直接通信。 | 跨集群网络通常存在 NAT、防火墙或 VPN 网关，原生调度器不处理这些拓扑约束。 |
| 无版本感知 | 调度器不关心 Node 上的 kubelet 版本、容器运行时版本或操作系统版本。 | 无法将需要特定 API 版本的 Pod 调度到版本匹配的集群，直接导致版本漂移问题。 |
关键认知： 原生调度器的“最优”是单集群内的局部最优，而跨集群调度需要的是全局最优，且必须纳入网络拓扑、版本兼容性等额外维度。
2.2 跨集群调度的核心挑战
跨集群调度并非简单地将多个 kube-scheduler 实例拼在一起。它面临三个相互交织的核心挑战：网络连通性、资源统一视图和版本一致性。下面这张架构图展示了这三个挑战在调度决策链路中的位置。
2.3 核心挑战深度解析
2.3.1 网络连通性：跨集群调度的第一道门槛
跨集群调度必须回答“Pod 调度到远端集群后，能否正常通信”。这不仅仅是 IP 可达性问题，还涉及：
- 控制面与数据面分离： 调度器（控制面）需要访问远端集群的 API Server，而 Pod（数据面）需要与远端 Service 或 Pod 通信，两者的网络路径可能完全不同。
- 延迟敏感型工作负载： 对于实时推理或数据库同步场景，跨集群网络延迟必须作为调度约束条件。
- 安全策略： 集群间通常存在严格的网络策略（NetworkPolicy）、服务网格 mTLS 或 VPN 隧道，调度器需要感知这些策略的生效范围。
实践建议： 在调度决策前，先通过集群联邦的“网络探针”或自定义资源（如 ClusterNetworkTopology）收集集群间的 RTT、带宽和防火墙规则，作为调度过滤条件。
2.3.2 资源统一视图：从“信息孤岛”到“全局资源池”
每个集群的 kube-scheduler 只维护本地 Node 的 ResourceMap。跨集群调度需要构建一个全局资源视图，但面临以下难点：
| 难点 | 说明 | 典型场景 |
|---|---|---|
| 数据一致性 | 各集群资源状态更新频率不同，全局视图存在秒级到分钟级的滞后。 | 集群 A 刚释放 100 个 CPU，但全局视图尚未更新，调度器可能错过机会。 |
| 资源异构 | 不同集群的 Node 可能使用不同的 CPU 架构（x86 vs ARM）、GPU 型号或内核版本。 | 需要 GPU 的 Pod 只能调度到配备 NVIDIA A100 的集群。 |
| 配额传递 | 每个集群有自己的 ResourceQuota 和 LimitRange，全局调度器需要理解这些边界。 | 集群 B 的 default 命名空间只剩 5 个 Pod 配额，全局调度器不能超额分配。 |
2.3.3 版本一致性：版本漂移的根源与校准需求
版本一致性是本章课程的核心关注点。在多集群环境中，版本差异是常态而非异常，其根源包括：
- 滚动升级不同步： 各集群的 Kubernetes 版本升级窗口不同，导致集群间 API 版本差异。
- 节点池异构： 同一集群内不同 Node 池可能运行不同版本的 kubelet 或操作系统。
- CRD 版本分裂： 自定义资源（CRD）在不同集群中可能处于不同的 API 版本（v1 vs v1beta1）。
版本不一致对调度的影响是致命的：
版本漂移风险示例： 假设集群 A 运行 Kubernetes 1.22，集群 B 运行 1.28。如果全局调度器将一个使用了
batch/v1beta1 CronJob API 的 Pod 调度到集群 B（该版本在 1.25 后被移除），Pod 将无法创建，导致调度失败。这就是版本漂移导致的“调度-运行时断裂”。
下面这张流程图展示了版本一致性检查在跨集群调度决策中的位置：
2.4 三个挑战的关联与权衡
网络、资源、版本三个挑战并非独立存在，它们在实际调度决策中相互制约：
- 网络 ↔ 资源： 网络延迟高的集群即使资源充足，也可能被延迟敏感型工作负载排除。
- 资源 ↔ 版本： 版本较新的集群可能拥有更多资源（如新 Node 加入），但旧版本集群可能运行着关键业务。
- 版本 ↔ 网络： 版本差异可能导致跨集群网络策略不兼容（如 NetworkPolicy API 版本变化）。