Kubernetes v1.37 InPlacePodVerticalScaling 如何检查原地调节条件

我第一次看 Kubernetes v1.37 的 InPlacePodVerticalScaling 时，最容易误判的是“Pod 没重建，就等于扩容成功”。实际上，原地调整至少要分开看四件事：集群版本和客户端、调度器抢占开关、节点余量，以及 Pod status 里记录的实际资源。官方文档地址：https://kubernetes.io/docs/

v1.37 的核心原地 Pod 调整已经稳定，但新增的 InPlacePodVerticalScalingSchedulerPreemption 仍是默认关闭的 Alpha 能力。只有请求先成为可延期的 Deferred，并且高优先级 Pod、节点和组件配置都满足条件，调度器才可能抢占同节点的低优先级 Pod 来腾出 CPU 或内存。

Kubernetes v1.37 先检查哪些条件

我会先把“版本支持”和“是否真的打开抢占”拆开。核心 in-place resize 自 v1.35 起是 Stable；v1.37 新增的是调度器为 Deferred resize 清理低优先级工作负载的路径，feature gate 名称很长，但它决定了这次新闻变化能不能在集群里出现。

本地试验可以用 kind 的集群配置表达开关，生产环境则要按组件的启动参数或配置文件核对，不要只看控制面某一个组件：

# kind-config.yaml：仅用于演示 v1.37 的调度器抢占开关
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
featureGates:
  InPlacePodVerticalScalingSchedulerPreemption: true

# 先确认客户端和服务端版本，避免把客户端报错误判成集群不支持
kubectl version

# 查看节点可分配 CPU，确认后续扩容是否有可观测的容量压力
kubectl get nodes -o custom-columns=NAME:.metadata.name,ALLOCATABLE_CPU:.status.allocatable.cpu

用 resize 子资源提交一次可控的扩容

检查条件后，不要直接改 Deployment 模板来验证这个能力，因为那会走替换 Pod 的常规路线。应该针对正在运行的 Pod 使用 /resize 子资源。下面的示例把高优先级容器的 CPU 从 4 调到 6；它是复现实验的命令，不代表当前环境已经执行。

# 只更新 resize 子资源中的容器 CPU，保持 Pod 身份不变
kubectl patch pod high-priority-pod --subresource resize --patch \
  '{"spec":{"containers":[{"name":"app","resources":{"requests":{"cpu":"6"},"limits":{"cpu":"6"}}}]}}'

# 查看 kubelet 是否记录了 Pending、Deferred 或 InProgress 条件
kubectl get pod high-priority-pod -o jsonpath='{.status.conditions}'

# 读取该 Pod 的事件，区分资源不足和后续开始/完成
kubectl get events --field-selector involvedObject.name=high-priority-pod

如果节点原本只剩 1 个 CPU，而请求增加 2 个 CPU，kubelet 可能先写入 PodResizePending 与 reason: Deferred。这表示请求暂时无法执行、以后可能因其他 Pod 缩容而可行；若是 Infeasible，则是当前节点或约束下根本不可行，不能靠等待解决。

Deferred 之后如何确认调整真的完成

我更愿意把事件和 status 放在一起看。只看 spec.containers[].resources 只能证明期望值改了；还要看 status.containerStatuses[].resources 是否已经反映节点上的实际配置。启用相关状态字段时，也可以用 allocatedResources 做更直接的复核。

# 查看容器当前由 kubelet 反映的实际 CPU 配置
kubectl get pod high-priority-pod -o jsonpath='{.status.containerStatuses[0].resources.cpu}'; echo

# 高级复核：确认节点已分配给容器的 CPU 值
kubectl get pod high-priority-pod -o jsonpath='{.status.containerStatuses[0].allocatedResources.cpu}'; echo

# 观察低优先级 Pod 是否出现调度器的 Preempted 事件
kubectl get events --field-selector involvedObject.name=low-priority-pod

理想的事件顺序是 ResizeDeferred、低优先级 Pod 的 Preempted，再到 ResizeStarted 和 ResizeCompleted。最后确认 allocated CPU 为 6；如果容器的 CPU resizePolicy 是 NotRequired，还可以观察到 restartCount 不因这次 CPU 调整增加。

几个容易把结果看错的边界

第一，抢占只在当前 Pod 所在节点上找低优先级候选，不是重新为这个运行中 Pod 做一次全局选址；PriorityClass、PDB 和优雅终止策略都会影响实际结果。第二，v1.37 的原地调整主要覆盖 CPU 和内存，不能借 /resize 顺手修改任意资源。第三，内存变更可以按 resizePolicy 选择是否重启容器，默认策略并不等于所有运行时都能无感调整。

还要记住原来的 QoS 类别不能靠 resize 随意改变：Guaranteed 仍须保持 requests 等于 limits，BestEffort 不能突然添加资源要求；init 容器和 ephemeral 容器不能按这条路径调整，Windows Pod 也不支持 in-place resize。遇到失败时先看 Pending condition 的 reason 和 message，再决定是释放容量、调整优先级设计，还是回到工作负载控制器滚动替换。

相关问题

Deferred 和 Infeasible 最大的区别是什么？

Deferred 表示请求现在暂时执行不了，但容量或条件变化后可能成功；Infeasible 表示当前节点、配额或约束下不可行。v1.37 的调度器抢占路径针对前者。

开启抢占 gate 后，所有 Pod 都会被优先级更高的请求驱逐吗？

不会。它只围绕 Deferred 的原地 resize，在已分配节点上寻找较低优先级候选，并仍受 PDB、终止策略和节点策略影响。

为什么 spec 已经变成 6 CPU，status 还是旧值？

spec 是期望资源，status.containerStatuses[].resources 才反映 kubelet 当前已配置资源。两者短暂不一致时，应继续看 Pending/InProgress 条件、事件和 observedGeneration。