From aa173996ea1a7685365d3594cace8bedc879f90c Mon Sep 17 00:00:00 2001 From: zhuzhenghao Date: Sun, 5 Feb 2023 16:55:10 +0800 Subject: [PATCH] [zh] Resync scheduling-framework.md --- .../scheduling-framework.md | 126 +++++++++++------- 1 file changed, 78 insertions(+), 48 deletions(-) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md index 5c4f5c4a4c..2641362e0a 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -16,7 +16,7 @@ weight: 60 -{{< feature-state for_k8s_version="1.19" state="stable" >}} +{{< feature-state for_k8s_version="v1.19" state="stable" >}} 这些插件用于对调度队列中的 Pod 进行排序。 -队列排序插件本质上提供 `less(Pod1, Pod2)` 函数。 +队列排序插件本质上提供 `Less(Pod1, Pod2)` 函数。 一次只能启动一个队列插件。 如果任何 NormalizeScore 插件返回错误,则调度阶段将终止。 +{{< note >}} -{{< note >}} 希望执行“预保留”工作的插件应该使用 NormalizeScore 扩展点。 {{< /note >}} - -### Reserve +### Reserve {#reserve} -Reserve 是一个信息性的扩展点。 -管理运行时状态的插件(也成为“有状态插件”)应该使用此扩展点,以便 -调度器在节点给指定 Pod 预留了资源时能够通知该插件。 -这是在调度器真正将 Pod 绑定到节点之前发生的,并且它存在是为了防止 -在调度器等待绑定成功时发生竞争情况。 +实现了 Reserve 扩展的插件,拥有两个方法,即 `Reserve` 和 `Unreserve`, +他们分别支持两个名为 Reserve 和 Unreserve 的信息处理性质的调度阶段。 +维护运行时状态的插件(又称 "有状态插件")应该使用这两个阶段, +以便在节点上的资源被保留和未保留给特定的 Pod 时得到调度器的通知。 + + +Reserve 阶段发生在调度器实际将一个 Pod 绑定到其指定节点之前。 +它的存在是为了防止在调度器等待绑定成功时发生竞争情况。 +每个 Reserve 插件的 `Reserve` 方法可能成功,也可能失败; +如果一个 `Reserve` 方法调用失败,后面的插件就不会被执行,Reserve 阶段被认为失败。 +如果所有插件的 `Reserve` 方法都成功了,Reserve 阶段就被认为是成功的, +剩下的调度周期和绑定周期就会被执行。 + + +如果 Reserve 阶段或后续阶段失败了,则触发 Unreserve 阶段。 +发生这种情况时,**所有** Reserve 插件的 `Unreserve` 方法将按照 +`Reserve` 方法调用的相反顺序执行。 +这个阶段的存在是为了清理与保留的 Pod 相关的状态。 + +{{< caution >}} + +Reserve 插件中 `Unreserve` 方法的实现必须是幂等的,并且不能失败。 +{{< /caution >}} 1. **拒绝** \ 如果任何 Permit 插件拒绝 Pod,则该 Pod 将被返回到调度队列。 - 这将触发[Unreserve](#unreserve) 插件。 + 这将触发 [Reserve 插件](#reserve)中的 Unreserve 阶段。 1. **等待**(带有超时) \ 如果一个 Permit 插件返回 “等待” 结果,则 Pod 将保持在一个内部的 “等待中” - 的 Pod 列表,同时该 Pod 的绑定周期启动时即直接阻塞直到得到 - [批准](#frameworkhandle)。如果超时发生,**等待** 变成 **拒绝**,并且 Pod - 将返回调度队列,从而触发 [Unreserve](#unreserve) 插件。 - + 的 Pod 列表,同时该 Pod 的绑定周期启动时即直接阻塞直到得到批准。 + 如果超时发生,**等待** 变成 **拒绝**,并且 Pod + 将返回调度队列,从而触发 [Reserve 插件](#reserve)中的 Unreserve 阶段。 +{{< note >}} -{{< note >}} 尽管任何插件可以访问 “等待中” 状态的 Pod 列表并批准它们 (查看 [`FrameworkHandle`](https://git.k8s.io/enhancements/keps/sig-scheduling/624-scheduling-framework#frameworkhandle))。 我们期望只有允许插件可以批准处于 “等待中” 状态的预留 Pod 的绑定。 @@ -338,7 +370,7 @@ is approved, it is sent to the [PreBind](#pre-bind) phase. {{< /note >}} ### PreBind {#pre-bind} @@ -352,10 +384,10 @@ target node before allowing the Pod to run there. 将其挂载到目标节点上。 -如果任何 PreBind 插件返回错误,则 Pod 将被 [拒绝](#unreserve) 并且 +如果任何 PreBind 插件返回错误,则 Pod 将被 [拒绝](#reserve) 并且 退回到调度队列中。 -# 插件配置 +## 插件配置