首页/云/Kubernetes 速查/SchedulingGates 暂停调度
调度与资源52 条

SchedulingGates 暂停调度

schedulingGates 让 Pod 创建后停在 SchedulingGated 状态,由外部控制器移除门后才进入调度:适合先备好资源再放行。

Kubernetes 速查云更新于 2026-10-13

SchedulingGates 是什么

schedulingGates 是 Pod 规格里的一个列表,用来把 Pod「挂起」在调度之前。带门的 Pod 创建成功后不会进入调度队列,而是停在 Pending,状态条件里写明 reason 为 SchedulingGated;直到外部控制器把门移除,Pod 才被调度器正常处理。它解决的是顺序问题:由谁在什么时候决定 Pod 可以开始占资源,交给集群外的业务逻辑判断,而不是靠固定等待时间凑。

基本信息

字段位置Pod.spec.schedulingGates[],每个门只有一个 name 属性
引入版本v1.26 alpha、v1.27 beta,特性名为 PodSchedulingReadiness,老集群先确认是否可用
可变性Pod 创建后门只能被移除,不能新增或改名
典型实现者自定义控制器、平台侧的「资源就绪再放行」逻辑、批处理调度器
相关状态status.phase=Pending,PodScheduled=False 且 reason=SchedulingGated

典型使用场景

  • 等 GPU 驱动、设备插件或大镜像预热完成后再放行,避免 Pod 先占节点再反复失败
  • 平台侧配额与网络资源先就绪:由控制器确认条件后统一放行一批工作负载
  • 配合批处理调度器:先把 Pod 造出来排队,由外部调度逻辑决定适配的节点与时机
  • 灰度发布时把新版本 Pod 先挂住,等数据库迁移或流量切换完成再解除
  • 测试场景里验证调度顺序假设:确认「Pod 已创建」不等于「已经开始占资源」

声明门控

声明门控
apiVersion: v1
kind: Pod
metadata:
  name: gated-pod
spec:
  schedulingGates:
    - name: gpu-resource-ready     # 门名由你自己定义,语义由外部控制器实现
  containers:
    - name: app
      image: registry.example.com/worker:1.0.0
      resources:
        nvidia.com/gpu: 1          # 门控期间不会占用这些资源

核对与放行

核对与放行
kubectl get pod gated-pod -o jsonpath='{.status.phase} {.status.conditions[?(@.type=="PodScheduled")].reason}{"\n"}'   # 期望 Pending SchedulingGated
kubectl get pod gated-pod -o jsonpath='{.spec.nodeName}{"\n"}'   # 门控期间为空,说明还没绑定节点
kubectl patch pod gated-pod --type=json -p='[{"op":"remove","path":"/spec/schedulingGates/0"}]'   # 移除单个门
kubectl patch pod gated-pod --type=merge -p '{"spec":{"schedulingGates":null}}'   # 一次清空全部门
kubectl get events --field-selector involvedObject.name=gated-pod   # 门控期间不会有调度失败事件,别把它当成资源不足

门控前后状态对照

观察点门控中放行之后
status.phasePendingPending 转为 Running
PodScheduled 条件False,reason=SchedulingGatedTrue,或换成常规调度失败原因
spec.nodeName空值由调度器回填节点名
调度器事件没有调度器产生的 FailedScheduling出现 Scheduled 或 FailedScheduling
门控中的 Pod 不参与调度,也就不占用节点资源;但它依然计入命名空间的 Pod 数量配额,并且会出现在 Deployment、Job 等控制器的副本统计里,排障时不要把它当成「不存在的 Pod」忽略掉。
放行动作是 patch 掉 schedulingGates 里的条目,通常由自定义控制器用 ServiceAccount 完成:需要给该控制器单独的 RBAC(能改 Pod 的这个字段),不要直接把集群管理权限发给它。
门控不是启动顺序编排工具:它只保证「不被调度」,不保证依赖服务已经就绪。放行条件要在控制器里真正去探测(健康检查、就绪探针、外部接口),用固定睡眠时间凑出来的顺序在压力大时会原形毕露。

易错点

  • 门控创建后只能删除、不能新增或改名:控制器把门名写错就只能删掉 Pod 重建,门名与清理逻辑应当一起纳入版本管理
  • 长期停在 SchedulingGated 不是资源不足:往节点容量、污点、配额方向查会白费时间,先看 PodScheduled 条件的 reason
  • 集中放行形成调度洪峰:几百个 Pod 同时解除门控,调度器与 kubelet 短时间被打满,应分批释放或错峰
  • 忘记移除门会让 Deployment 滚动更新卡住:新副本永远不 Ready,受 maxSurge、maxUnavailable 影响,整次发布可能停摆且不报错
  • 控制器或 RBAC 未就绪就批量下发带门的 Pod:没人能放行,Pod 永久 Pending,同时一直占着 Pod 数量配额

数据来源与参考

  • Kubernetes 官方文档 · Pod 调度门控(SchedulingGates)
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌