Kubernetes v1.37 Pod 原地扩容抢占如何影响调度队列

Kubernetes v1.37 新增了一个容易被误解的调度变化：当已经运行的 Pod 请求原地扩容，却因为节点没有足够 CPU 或内存而进入 Deferred，调度器可以在同一节点抢占低优先级 Pod，为这次扩容腾出空间。

它到底改变了哪一段调度队列

普通 Pod 在初次创建时进入调度队列，成功绑定后就离开主动调度流程。原地扩容则不同：Pod 已经有 spec.nodeName，但新的资源请求可能暂时无法兑现。v1.37 的这项能力会关注带有 Deferred 状态的已绑定 Pod，让它重新参与与资源有关的调度评估。

关键点是“差值”而不是“总量”。例如 Pod 当前使用 4 个 CPU，希望扩到 6 个 CPU，调度器要找的是额外 2 个 CPU。这个扩容请求仍然算作该节点上的资源占用，避免其他低优先级 Pod 在等待期间再次把空间填满。

为什么不会把扩容中的 Pod 重新绑定

这不是一次新的放置决策。调度器只在 Pod 原节点上寻找可抢占的低优先级对象；即使其他节点有空间，也不会把正在运行的 Pod 搬过去。成功选出受害者后，调度器释放本地容量，但不会重新设置 nominatedNodeName，也不会再次绑定这个 Pod。kubelet 看到容量释放后，才会完成实际的原地资源调整。

因此，观察日志时要把两个动作分开：Preempted 说明低优先级 Pod 被选中，ResizeStarted 和 ResizeCompleted 才说明高优先级 Pod 的新资源已经被 kubelet 接管。

如何在 v1.37 做一个最小验证

官方资料要求相关控制面组件和 kubelet 都开启特性门控。可以先用单节点 kind 环境验证，生产集群不要直接照搬实验资源。

# 创建 kind 配置：只为受控实验打开 Alpha 特性
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
  InPlacePodVerticalScalingSchedulerPreemption: true

# 使用 v1.37 或更高版本的节点镜像创建实验集群
kind create cluster --config kind-config.yaml --image kindest/node:v1.37.0

实验中让节点只剩少量 CPU 余量：先运行一个低优先级 Pod，再给高优先级 Pod 请求一次超过余量的原地扩容。

# 只修改 app 容器的目标资源；--subresource resize 表示原地扩容
kubectl patch pod high-priority-pod --subresource resize --patch \
  '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"6"},"limits":{"cpu":"6"}}}]}}'

# 查看低优先级 Pod 是否收到调度器的抢占事件
kubectl get events --field-selector involvedObject.name=low-priority-pod

# 查看 kubelet 最终写入的容器 CPU 分配
kubectl get pod high-priority-pod \
  -o jsonpath='{.status.containerStatuses[0].allocatedResources.cpu}{"\n"}'

预期顺序是先看到扩容因 OutOfcpu 进入 ResizeDeferred，随后低优先级 Pod 出现 Preempted，最后高优先级 Pod 出现 ResizeStarted 和 ResizeCompleted。事件顺序可能受终止宽限期影响，不要只凭一次命令输出判断扩容是否成功。

和普通 Pod 抢占相比，队列行为有哪些不同

这也解释了标题中的“调度队列”：队列里新增的不是一个等待迁移的 Pod，而是一个等待当前节点资源兑现的扩容请求。多个 Deferred 扩容同时存在时，高优先级优先；同优先级下，Guaranteed 先于 Burstable，仍相同则等待更久的请求优先。

上线前先处理两个风险

第一，Alpha 特性默认关闭，控制面和 kubelet 的门控配置必须一致，不能只改 scheduler。第二，节点级策略可以关闭 resize 抢占，适合交给自定义自动扩容器或节点调节器处理资源缺口：

这个列表最多 20 项，条目要符合 Kubernetes label key 格式。灰度时建议同时记录被抢占工作负载、扩容等待时间和节点实际余量；如果节点有特殊驱逐保护或容量由外部系统管理，应先用该字段关闭抢占，再验证外部控制器是否能及时补足资源。

常见问题

开启后会跨节点抢占吗？

不会。原地扩容抢占只在 Pod 当前所在节点寻找受害者，其他节点的空闲资源不会被用来迁移这个 Pod。

扩容请求被 Deferred 就一定会驱逐 Pod 吗？

不一定。还要满足特性门控开启、节点上存在合适的低优先级受害者，并且释放后足以满足扩容差值。

为什么看到 Preempted 但资源仍没变？

Preempted 只是释放容量的中间结果，终止宽限期和 kubelet 重新执行 resize 都需要时间，应继续观察 ResizeStarted 与 ResizeCompleted。

v1.35 以上是否自动拥有这个能力？

原地 Pod 垂直扩缩本身已稳定，但“扩容触发调度器抢占”是 v1.37 的 Alpha 增量，仍需显式开启对应特性门控。