📚 课程目录第4章调度策略引擎

4、调度策略引擎：静态调度策略(Spread/Replica)、动态调度策略(负载感知)、自定义调度插件框架

在联邦集群（Federation）中，调度策略引擎是决定工作负载如何跨多个成员集群分布的核心组件。它需要同时满足资源均衡、高可用、性能优化以及业务定制化需求。本章将深入剖析三种层次的调度策略：静态调度策略（Spread/Replica）、动态调度策略（负载感知）以及自定义调度插件框架，并展示它们在工程落地中的实现机制。

4.1 静态调度策略：Spread 与 Replica 调度

静态调度策略基于预定义的规则和集群的静态属性（如集群名称、区域、节点数量）进行决策，不依赖实时负载数据。在 Federation 中，最核心的两种静态策略是 Spread（分散调度） 和 Replica（副本调度）。

核心概念： Spread 策略旨在将 Pod 均匀分布到多个集群，以最大化可用性和故障域隔离；Replica 策略则允许用户精确控制每个集群应运行的副本数量，适用于需要固定资源预留的场景。

4.1.1 Spread 调度策略

Spread 调度通过计算每个集群的“已调度副本数”与“目标权重”的比值，优先将 Pod 调度到比值最低的集群，从而实现全局负载均衡。其核心算法可抽象为：

// 伪代码：Spread 调度决策
func spreadScore(cluster ClusterInfo, desiredReplicas int) float64 {
    // 已调度副本数 / (集群权重 * 总副本数)
    ratio := float64(cluster.ScheduledReplicas) / float64(cluster.Weight * desiredReplicas)
    return 1.0 - ratio  // 比值越低，得分越高
}

4.1.2 Replica 调度策略

Replica 策略则更为直接，它允许用户为每个集群指定一个固定的副本数或百分比。调度器会确保每个集群的当前副本数严格匹配预设值，适用于有状态服务或需要严格资源配额控制的场景。

策略类型	调度依据	适用场景	优点	缺点
Spread	集群权重 + 已调度副本数	无状态服务、全局负载均衡	自动均衡，故障域隔离好	无法精确控制每个集群的副本数
Replica	用户预设的集群副本数	有状态服务、资源配额固定	精确控制，行为可预测	缺乏弹性，可能造成资源浪费

4.2 动态调度策略：负载感知调度

静态策略无法应对集群间实时负载不均的问题。动态调度策略通过采集各成员集群的 实时指标（如 CPU 利用率、内存使用率、网络延迟、GPU 利用率等），动态调整调度决策，将 Pod 调度到当前负载最轻或资源最充裕的集群。

4.2.1 负载感知调度架构

动态调度引擎通常包含三个核心组件：指标采集器（Metrics Collector）、评分计算器（Scorer）和 调度决策器（Scheduler）。

指标采集器：通过 Prometheus、Metrics Server 或自定义 Agent 从各集群拉取实时负载数据，并缓存到 Federation 控制面。
评分计算器：根据采集到的指标，结合用户配置的权重（如 CPU 权重 0.6、内存权重 0.4），计算每个集群的综合负载得分。
调度决策器：选择得分最高（负载最低）的集群作为目标集群，并触发调度。

  工程实践： 为避免指标抖动导致频繁调度，通常引入“稳定窗口”机制——只有当目标集群的负载得分连续 N 次（如 3 次）优于当前集群时，才执行迁移。同时，需设置“最小调度间隔”防止调度风暴。

4.2.2 负载感知调度算法示例

// 伪代码：负载感知评分函数
func loadAwareScore(clusterMetrics Metrics, weights map[string]float64) float64 {
    cpuScore := 1.0 - (clusterMetrics.CPUUsage / 100.0)
    memScore := 1.0 - (clusterMetrics.MemUsage / 100.0)
    // 加权综合得分
    totalScore := weights["cpu"] * cpuScore + weights["mem"] * memScore
    return totalScore
}

指标类型	采集方式	权重配置示例	说明
CPU 利用率	Prometheus Node Exporter	0.5	反映计算资源紧张程度
内存利用率	Metrics Server	0.3	反映内存资源紧张程度
网络延迟	自定义 Agent	0.1	反映集群间网络质量
GPU 利用率	DCGM Exporter	0.1	AI/ML 场景专用指标

4.3 自定义调度插件框架

静态和动态策略无法覆盖所有业务场景。为此，Federation 调度引擎提供了 自定义调度插件框架，允许开发者以插件形式注入自定义调度逻辑，实现高度灵活的调度策略。

4.3.1 插件框架架构

插件框架采用“扩展点 + 插件链”模式。调度器在关键决策点（如 Filter、Score、Bind）预留扩展接口，用户通过实现这些接口来注册自定义插件。调度器按顺序执行插件链，每个插件可以对候选集群进行过滤、评分或绑定操作。

Filter 插件：用于排除不满足条件的集群（如集群标签不匹配、资源不足）。
Score 插件：为每个候选集群打分，得分最高的集群被选中。
Bind 插件：在调度决策后执行自定义绑定逻辑（如记录审计日志、触发预热）。

注意事项： 自定义插件应遵循“无副作用”原则，避免在 Filter/Score 阶段修改全局状态。同时，插件应具备良好的性能，避免因复杂计算阻塞调度主流程。建议为插件设置超时时间（如 5s）。

4.3.2 插件开发示例

以下是一个简单的“集群亲和性”评分插件示例，它根据集群的“region”标签为 Pod 打分：

// 自定义评分插件：集群亲和性
type AffinityPlugin struct{}

func (p *AffinityPlugin) Name() string {
    return "ClusterAffinity"
}

func (p *AffinityPlugin) Score(cluster *ClusterInfo, pod *PodInfo) (int64, error) {
    // 如果 Pod 指定了 preferredRegion，则优先调度到该 region 的集群
    if preferredRegion, ok := pod.Labels["preferred-region"]; ok {
        if cluster.Labels["region"] == preferredRegion {
            return 100, nil  // 最高分
        }
    }
    return 0, nil
}

4.3.3 插件注册与优先级

插件通过配置文件注册，并指定执行优先级。调度器按优先级从高到低执行插件链。

插件名称	类型	优先级	说明
NodeResourcesFit	Filter	10	内置插件：检查集群资源是否满足 Pod 请求
ClusterAffinity	Score	20	自定义插件：根据 region 标签打分
LoadAware	Score	30	内置插件：负载感知评分
AuditBind	Bind	5	自定义插件：记录调度审计日志

  工程落地建议： 在 Federation 项目中，建议将自定义插件打包为独立的 gRPC 服务，通过“远程插件”方式集成，避免插件崩溃影响调度器主进程。同时，提供插件健康检查和降级机制，确保调度链的稳定性。

4.4 策略组合与调度链

在实际工程中，单一策略往往无法满足复杂需求。Federation 调度引擎支持将多种策略组合成 调度链，按顺序执行。典型的调度链如下：

Filter 阶段：执行所有 Filter 插件，排除不满足条件的集群。
Score 阶段：依次执行 Spread、Replica、负载感知、自定义评分插件，每个插件返回一个 0-100 的分数。
权重聚合：根据用户配置的权重（如 Spread 权重 0.3、负载感知权重 0.7），计算每个集群的加权总分。
选择最优：选择总分最高的集群作为调度目标。
Bind 阶段：执行 Bind 插件，完成调度绑定。

这种组合方式既保留了静态策略的稳定性，又引入了动态策略的灵活性，同时通过自定义插件满足业务定制需求，是 Federation 调度策略引擎的核心设计思想。