Kubernetes 1.26:Pod 调度就绪态

2023年 7月 11日 40.8k 0

作者: Wei Huang (Apple), Abdullah Gharaibeh (Google)

译者: XiaoYang Zhang (HuaWei)

Kubernetes 1.26 引入了一个新的 Pod 特性:调度门控。
在 Kubernetes 中,调度门控是通知调度器何时可以考虑 Pod 调度的关键。

它解决了什么问题?

当 Pod 被创建时,调度器会不断尝试寻找适合它的节点。这个无限循环一直持续到调度程序为 Pod 找到节点,或者 Pod 被删除。

长时间无法被调度的 Pod(例如,被某些外部事件阻塞的 Pod)会浪费调度周期。
一个调度周期可能需要约 20ms 或更长时间,这取决于 Pod 的调度约束的复杂度。
因此,大量浪费的被调度周期会严重影响调度器的性能。请参阅下面 “调度器” 框中的箭头。

graph LR;
pod((新 Pod))-->queue
subgraph 调度器
queue(调度器队列)
sched_cycle[/调度周期/]
schedulable{可调度?}
queue==>|弹出|sched_cycle
sched_cycle==>schedulable
schedulable==>|否|queue
subgraph note [循环浪费在不断重新安排 'unready' 状态的 Pod 上]
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((新 Pod))-->queue
subgraph 调度器
queue(调度器队列)
sched_cycle[/调度周期/]
schedulable{可调度?}
popout{弹出?}
queue==>|PreEnqueue 检查|popout
popout-->|是|sched_cycle
popout==>|否|queue
sched_cycle-->schedulable
schedulable-->|否|queue
subgraph note [控制 Pod 调度的开关]
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;

它是如何工作的?

总体而言,调度门控的工作方式与 Finalizer 非常相似。具有非空 spec.schedulingGates 字段的 Pod
的状态将显示为 SchedulingGated,并阻止被调度。请注意,添加多个门控是可以的,但它们都应该在创建 Pod
时添加(例如,你可以将它们作为规约的一部分或者通过变更性质的 Webhook)。

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

要清除这些门控,你可以通过删除 Pod 的 schedulingGates 字段中的所有条目来更新 Pod。
不需要一次性移除所有门控,但是,只有当所有门控都移除后,调度器才会开始考虑对 Pod 进行调度。

在后台,调度门控以 PreEnqueue 调度器插件的方式实现,这是调度器框架的新扩展点,在每个调度周期开始时调用。

用例

此特性所支持的一个重要使用场景是动态配额管理。Kubernetes 支持资源配额,
但是 API Server 会在你尝试创建 Pod 时强制执行配额。例如,如果一个新的 Pod 超过了 CPU 配额,它就会被拒绝。
API Server 不会对 Pod 进行排队;因此,无论是谁创建了 Pod,都需要不断尝试重新创建它。
这意味着在资源可用和 Pod 实际运行之间会有延迟,或者意味着由于不断尝试,会增加 API Server 和 Scheduler 的负载。

调度门控允许外部配额管理器解决 ResourceQuota 的上述限制。具体来说,
管理员可以(使用变更性质的 Webhook)为集群中创建的所有 Pod 添加一个
example.com/quota-check 调度门控。当存在用于启动 Pod 的配额时,管理器将移除此门控

接下来

要使用此特性,必须在 API Server 和调度器中启用 PodScheduleingReadiness 特性门控。
非常欢迎你对其进行测试并告诉我们(SIG Scheduling)你的想法!

附加资源

  • Kubernetes 文档中的 Pod 调度就绪态
  • Kubernetes 增强提案

相关文章

KubeSphere 部署向量数据库 Milvus 实战指南
探索 Kubernetes 持久化存储之 Longhorn 初窥门径
征服 Docker 镜像访问限制!KubeSphere v3.4.1 成功部署全攻略
那些年在 Terraform 上吃到的糖和踩过的坑
无需 Kubernetes 测试 Kubernetes 网络实现
Kubernetes v1.31 中的移除和主要变更

发布评论