1. Federation 架构概述
1.1 Federation V2 与 Karmada 的演进
Kubernetes 社区在跨集群管理领域经历了从 Federation V1 到 Federation V2，再到云原生计算基金会（CNCF）孵化项目 Karmada 的演进过程。每一次迭代都试图解决上一代架构在扩展性、资源抽象和调度灵活性上的不足。
| 维度 | Federation V1 | Federation V2 | Karmada |
|---|---|---|---|
| 架构模式 | 集中式 API 代理 | CRD + Controller 模式 | 声明式调度引擎 + 插件化调度器 |
| 资源抽象 | Federated API 对象 | Template / Placement / Override | ResourceTemplate + PropagationPolicy + ClusterOverridePolicy |
| 调度策略 | 静态副本拆分 | ReplicaSchedulingPreference | 动态调度 + 重调度 + 差异化调度 |
| 集群状态 | 全量同步 | 条件推送 | 资源模板 + 差异化推送 |
| 社区状态 | 已归档 | 维护模式 | CNCF 孵化项目（活跃） |
Karmada 继承了 Federation V2 的 CRD 驱动思想，但引入了更灵活的调度框架和资源模型，使得跨集群调度不再局限于简单的副本拆分，而是能够基于多维度的资源约束进行智能分发。
关键演进节点： Federation V2 提出了 Template / Placement / Override 三层资源抽象，Karmada 将其演化为 PropagationPolicy（传播策略）与 ClusterOverridePolicy（集群覆盖策略），并新增了 ResourceInterpreter（资源解释器）来支持自定义资源的跨集群调度。
1.2 跨集群调度的核心挑战
跨集群调度并非简单地将单集群调度器水平扩展。在多集群环境下，调度系统面临以下四个核心挑战：
- 资源异构性： 不同集群的节点规格、GPU 型号、存储类型、网络拓扑存在差异，调度器需要感知并利用这些差异。
- 状态不一致性： 各集群的资源使用率、节点健康状态、Pod 运行状态存在延迟，调度决策基于的全局视图可能过时。
- 策略冲突： 全局调度策略（如地域亲和、成本优化）与集群本地调度策略（如节点选择器、污点容忍）可能产生冲突。
- 调度稳定性： 跨集群调度失败后的回滚、重调度、资源预留释放等机制需要保证系统整体稳定性。
| 挑战维度 | 具体表现 | 对资源模型的影响 |
|---|---|---|
| 资源异构性 | 集群 A 有 GPU，集群 B 无 GPU | 资源模型需支持自定义资源维度（如 GPU 型号、显存） |
| 状态不一致性 | 集群 A 报告 80% 利用率，实际已 95% | 资源模型需引入时间戳和置信度标记 |
| 策略冲突 | 全局要求 3 副本，本地限制 2 副本 | 资源模型需支持策略优先级和覆盖机制 |
| 调度稳定性 | 集群 A 调度失败，Pod 被重新调度到集群 B | 资源模型需记录调度历史和失败原因 |
工程陷阱： 许多团队在实现跨集群调度时，直接复用单集群调度器的资源模型，导致无法感知集群间的资源差异。例如，两个集群都报告 "CPU 剩余 10 核"，但一个集群的 CPU 是 Intel Xeon，另一个是 AMD EPYC，性能差异可达 20% 以上。资源模型必须能够承载这种异构信息。
1.3 资源模型在调度中的定位
资源模型是跨集群调度系统的核心数据抽象，它定义了调度器如何描述、查询和比较不同集群的资源能力。在 Federation 架构中，资源模型处于调度决策链的中间层：
- 上层： 用户通过 PropagationPolicy 声明调度意图（如 "将 70% 的流量调度到华东集群"）。
- 中间层： 资源模型将用户意图转化为可量化的资源约束（如 "华东集群剩余 CPU 120 核，内存 256 GB，满足 70% 流量需求"）。
- 下层： 调度引擎根据资源模型提供的约束条件，执行具体的调度算法（如加权轮询、最小负载优先）。
资源模型在调度中的具体职责包括：
- 资源描述： 定义跨集群资源的统一数据结构，包括 CPU、内存、GPU、存储、网络带宽等维度。
- 资源聚合： 将多个集群的资源信息汇总为全局资源视图，支持按地域、可用区、集群标签等维度进行聚合。
- 资源约束： 根据 PropagationPolicy 中的调度策略，生成每个集群的资源约束条件（如 "至少剩余 10 核 CPU"）。
- 资源比较： 提供集群间的资源排序和打分能力，支持 "最小负载优先"、"成本优先" 等调度策略。
工程建议： 在设计资源模型时，建议采用 插件化 架构。将资源维度的定义、聚合逻辑、比较算法抽象为插件接口，这样当新的资源类型（如 DPU、FPGA）出现时，只需新增插件即可扩展资源模型，无需修改调度核心代码。