这篇文章已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes 1.26：Pod 调度就绪

作者：Wei Huang (Apple), Abdullah Gharaibeh (Google) |

Kubernetes 1.26 引入了一个新的 Pod 功能：调度门控。在 Kubernetes 中，调度门控是告知调度器 Pod 何时准备好被考虑调度的键。

它解决了什么问题？

创建 Pod 时，调度器会不断尝试查找适合它的节点。此无限循环会一直持续到调度器找到 Pod 的节点或 Pod 被删除为止。

长时间保持不可调度的 Pod（例如，被某些外部事件阻塞的 Pod）会浪费调度周期。根据 Pod 调度约束的复杂性，一个调度周期可能需要 ≅20 毫秒或更长时间。因此，在大规模情况下，这些浪费的周期会显着影响调度器的性能。请参见下面“调度器”框中的箭头。

graph LR; pod((New Pod))-->queue subgraph Scheduler queue(scheduler queue) sched_cycle[/scheduling cycle/] schedulable{schedulable?} queue==>|Pop out|sched_cycle sched_cycle==>schedulable schedulable==>|No|queue subgraph note [Cycles wasted on keep rescheduling 'unready' Pods] end end classDef plain fill:#ddd,stroke:#fff,stroke-width:1px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff; classDef Scheduler fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; classDef note fill:#edf2ae,stroke:#fff,stroke-width:1px; class queue,sched_cycle,schedulable k8s; class pod plain; class note note; class Scheduler Scheduler;

调度门控有助于解决此问题。它允许声明新创建的 Pod 尚未准备好进行调度。当 Pod 上存在调度门控时，调度器会忽略 Pod，从而节省不必要的调度尝试。如果集群中安装了 Cluster Autoscaler，这些 Pod 也将被其忽略。

清除门控的责任在于外部控制器，它们知道何时应该考虑调度 Pod（例如，配额管理器）。

graph LR; pod((New Pod))-->queue subgraph Scheduler queue(scheduler queue) sched_cycle[/scheduling cycle/] schedulable{schedulable?} popout{Pop out?} queue==>|PreEnqueue check|popout popout-->|Yes|sched_cycle popout==>|No|queue sched_cycle-->schedulable schedulable-->|No|queue subgraph note [A knob to gate Pod's scheduling] end end classDef plain fill:#ddd,stroke:#fff,stroke-width:1px,color:#000; classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff; classDef Scheduler fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; classDef note fill:#edf2ae,stroke:#fff,stroke-width:1px; classDef popout fill:#f96,stroke:#fff,stroke-width:1px; class queue,sched_cycle,schedulable k8s; class pod plain; class note note; class popout popout; class Scheduler Scheduler;

它是如何工作的？

通常，调度门控的工作方式与 Finalizers 非常相似。具有非空 spec.schedulingGates 字段的 Pod 将显示为状态 SchedulingGated，并且会被阻止调度。请注意，可以添加多个门控，但是它们都应该在 Pod 创建时添加（例如，您可以将它们添加为 spec 的一部分或通过 mutating webhook）。

NAME       READY   STATUS            RESTARTS   AGE
test-pod   0/1     SchedulingGated   0          10s

要清除门控，您可以通过从 Pod 的 schedulingGates 字段中删除所有项来更新 Pod。门控不需要一次全部删除，只有当所有门控都删除后，调度器才会开始考虑调度 Pod。

在底层，调度门控被实现为 PreEnqueue 调度器插件，这是一个新的调度器框架扩展点，在每个调度周期的开始时调用。

用例

此功能支持的一个重要用例是动态配额管理。Kubernetes 支持 ResourceQuota，但是 API 服务器在您尝试创建 Pod 时强制执行配额。例如，如果新的 Pod 超出了 CPU 配额，它将被拒绝。API 服务器不会将 Pod 排队；因此，创建 Pod 的人需要不断尝试再次重新创建它。这意味着资源可用和 Pod 实际运行之间存在延迟，或者意味着由于不断尝试，API 服务器和调度器上的负载。

调度门控允许外部配额管理器解决上述 ResourceQuota 的限制。具体来说，管理器可以向集群中创建的所有 Pod 添加 example.com/quota-check 调度门控（使用 mutating webhook）。当有配额启动 Pod 时，管理器将删除该门控。

下一步是什么？

要使用此功能，必须在 API 服务器和调度器中启用 PodSchedulingReadiness 功能门控。欢迎您进行测试并告诉我们（SIG Scheduling）您的想法！

其他资源