k8s扩展调度能力的三种实现方式

Kubernetes 调度器扩展原理

Kubernetes 调度器扩展主要通过两种机制实现：

调度框架（Scheduling Framework）和调度器扩展器（Extender）。

前者是内置的可编程插件体系，后者是外部的独立服务。

调度框架（Scheduling Framework）

调度框架将调度过程分解为多个阶段，每个阶段允许通过插件扩展：

1. 调度周期（Scheduling Cycle）

• QueueSort插件：定义 Pod 的调度队列排序规则。
• PreFilter插件：检查 Pod 的调度前提条件（如资源请求是否合法）。
• Filter插件：替代原生的 Predicates 逻辑，过滤不满足条件的节点。
• PostFilter插件：当无可用节点时触发（如抢占逻辑）。
• PreScore插件：为 Score 阶段准备数据。
• Score插件：替代原生的 Priorities 逻辑，为节点打分。
• NormalizeScore插件：标准化分数到统一范围（如 0-100）。
• Reserve插件：预留资源（绑定前执行清理逻辑）。

2. 绑定周期（Binding Cycle）

• PreBind插件：绑定前执行（如挂载网络存储）。
• Bind插件：将 Pod 绑定到节点（默认实现为 API 调用）。
• PostBind插件：绑定后执行通知类操作。

插件通过实现接口注册到框架，例如：

type ScorePlugin interface {
    Score(ctx context.Context, state *CycleState, pod *v1.Pod, nodeName string) (int64, *Status)
}

调度器扩展器（Extender）

Extender 是独立于调度器的 HTTP 服务，通过配置 kube-scheduler 的 --policy-config-file 实现扩展：

1. 扩展点支持

• Filter：扩展节点过滤逻辑。
• Prioritize：扩展节点打分逻辑。
• Preempt：扩展抢占逻辑。
• Bind：扩展绑定逻辑。

2. 通信协议

调度器通过 HTTP POST 请求与 Extender 交互，请求体包含 Pod 和节点列表，响应返回过滤结果或打分。

示例 Filter 请求体：

{
  "Pod": {"metadata": {"name": "nginx"}},
  "Nodes": {"items": [{"metadata": {"name": "node-1"}}]}
}

3. 配置示例

{
  "extenders": [{
    "urlPrefix": "http://extender-service:80",
    "filterVerb": "filter",
    "prioritizeVerb": "prioritize",
    "weight": 1
  }]
}

自定义调度器（Custom Scheduler）

完全独立的调度器实现：

1. 监听未调度的 Pod（pod.spec.schedulerName 匹配自定义名称）。
2. 调用 Kubernetes API 完成绑定（需具备 bind 权限）。
3. 可与默认调度器共存，通过 schedulerName 区分。

性能与隔离考量

• 调度框架：插件运行在调度器进程中，性能高但可能影响稳定性。
• Extender：独立进程隔离性好，但 HTTP 通信有延迟。
• 自定义调度器：灵活性最高，但需重复实现基础功能。

典型场景选择：

• 简单策略扩展优先用调度框架插件。
• 复杂外部依赖（如对接内部系统）适合 Extender。
• 特殊调度需求（如批量任务）可开发自定义调度器。

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

最新评论