Schedule Framework

一、Scheduling Framework 调度框架概述

scheduling framework 是 Kubernetes 调度器的可插拔架构，它由一组直接编译到调度程序中的“plugin”API 组成。调度框架定义了一些扩展点，调度程序插件注册以在一个或多个扩展点处调用。

1.调度周期与绑定周期

每次尝试调度一个 Pod 都会分为两个阶段：

• scheduling cycle（调度周期）
• binding cycle（绑定周期）

调度周期为 Pod 选择一个节点，绑定周期将该决策提交给集群。调度周期和绑定周期一起被称为 “scheduling context”（调度上下文）。调度周期串行运行，而绑定周期可以并发运行。如果 Pod 被确定为不可调度或存在内部错误，则可以中止调度或绑定周期。 Pod 将返回队列并重试。

下图展示了Pod的调度上下文以及调度框架暴露的接口。

二、调度队列机制

1.PreEnqueue插件

PreEnqueue插件在将 Pod 添加到内部 active queue (活动队列)之前被调用，其中 Pod 被标记为准备调度。只有当所有 PreEnqueue 插件都返回 Success 时，Pod 才被允许进入活动队列。否则，它将被放置在内部不可调度的 Pod 列表中，并且不会获得 Unschedulable 条件。

2.排队机制

排队机制是调度程序的一个组成部分。它允许调度程序为下一个调度周期选择最合适的 Pod。鉴于 pod 可以指定调度时必须满足的各种条件，例如持久卷的存在、遵守 pod 反亲和性规则或节点污点的容忍度，该机制需要能够推迟调度操作直到集群满足调度成功的所有条件。该机制依赖于三个队列：

• activeQ：提供pod进行即时调度
• unschedulableQ：用于等待某些条件发生的pod
• podBackoffQ：以指数方式推迟未能调度的 pod（例如仍在创建卷）但预计最终会得到调度。

3.重试机制

调度队列采用指数退避机制来重试调度失败的 Pod。重试次数越多，Pod 重新进入活动队列所需的时间越长。重试算法采用的是 指数退避机制，默认情况下最小为 1 秒，最大为 10 秒，例如，重试 3 次的 Pod 下一次的重试等待时间为 2^3 = 8 秒。为了避免 Pod 经常调度失败而频繁进入等待队列，应该配置合理的退避时间基数，降低系统负载。

此外，调度队列机制有两个在后台运行的 goroutine, 负责定期刷新 将 Pod 加入到 Active 队列，当某些事件 (例如节点添加或更新、现有 Pod 被删除等) 触发时， 调度程序会将 UnSchedulable 队列或