Kubernetes v1.37：原地 Pod 调整的调度器抢占（Alpha）
内容提要
Kubernetes v1.37 引入原地 Pod 调整的调度器抢占（Alpha）。当高优先级 Pod 扩容超出节点容量而被延迟时，调度器可抢占同节点低优先级工作负载，释放资源使扩容完成。该机制与 Kubelet 职责分离，支持节点级禁用策略，提升集群利用率并保障关键服务。
延伸解读
原地调整的调度缺口与抢占机制
原地 Pod 调整允许不重启容器动态调整资源，但当扩容超出节点可分配余量时，Kubelet 会将 resizeStatus 置为 Deferred，请求被无限期挂起。v1.37 引入的调度器抢占（Alpha）填补了这一缺口：调度器主动驱逐同节点低优先级 Pod，释放容量使高优先级扩容得以完成。该机制与 Kubelet 职责分离，由调度器集中处理抢占逻辑，尊重全局优先级和 PDB。
节点级禁用策略与适用场景
管理员可通过 Node 的 spec.podPreemptionPolicy 字段禁用特定节点上的原地调整抢占，例如配置 disableResizePreemption 列表。这适用于希望优先缩容其他 Pod 或动态调整节点容量、仅将抢占作为最后手段的场景。该策略提供了灵活性，避免调度器抢占与集群自动扩缩容等控制器产生冲突，同时保留节点级别的控制粒度。
抢占的局部性与失败边界
与调度阶段的抢占不同，原地调整抢占严格限定在 Pod 当前所在节点，不会跨节点寻找更优放置。调度器仅识别同节点上的低优先级“受害者” Pod 并触发优雅驱逐。若驱逐所有合格低优先级负载后节点仍无法满足扩容需求，调整将保持 Deferred 状态。这一设计避免了全局调度震荡，但也意味着节点容量是硬边界，无法通过跨节点迁移解决。
操作验证与事件观察
在启用特性门控的 kind 集群中，可创建高低优先级 Pod 并触发高优先级 Pod 的扩容。当扩容超出节点余量时，调度器会拦截 Deferred 条件并抢占低优先级 Pod。通过 kubectl get events 可观察到低优先级 Pod 的 Preempted 事件，以及高优先级 Pod 从 ResizeDeferred 到 ResizeStarted、ResizeCompleted 的事件序列，最终确认 allocatedResources 已更新。这为测试和调试提供了明确路径。
Q&A
Kubernetes v1.37 中原地 Pod 调整的调度器抢占是什么？
这是 Kubernetes v1.37 引入的 Alpha 特性，允许调度器在节点资源不足时，通过抢占同节点上的低优先级工作负载，为高优先级 Pod 的原地扩容释放资源，使扩容得以完成。
为什么需要为原地 Pod 调整引入调度器抢占？
原地调整在 v1.35 达到 GA 后，若扩容请求超出节点可分配资源，Kubelet 会将 resizeStatus 标记为 Deferred，Pod 会无限期等待资源释放。此前调度器 unaware，无法通过优先级抢占为运行中的 Pod 腾出空间，导致关键应用可能因无法扩容而面临 OOM 等风险。
调度器抢占原地调整与普通调度抢占有何不同？
普通调度抢占会评估集群中所有节点以寻找最佳放置位置，而原地调整的抢占严格限定在 Pod 当前所在的节点上，仅抢占同节点上的低优先级 Pod，释放本地容量。
如何为特定节点禁用原地调整的调度器抢占？
可以通过 Node 的 spec.podPreemptionPolicy 字段配置，例如设置 disableResizePreemption 并指定相关注解，如 cluster-autoscaler.kubernetes.io/disable-preemption 或 operator.example.com/policy-override。
启用该特性后，Kubelet 和调度器的职责如何划分？
Kubelet 不再执行本地抢占检查或触发本地驱逐，而是将请求延迟并完全委托给调度器。调度器作为集中式编排器，统一管理所有与调整相关的抢占逻辑，遵循全局优先级、Pod 中断预算和优雅终止策略。
如何在本地 kind 集群中测试原地 Pod 调整的调度器抢占？
创建 kind 集群配置文件，启用 InPlacePodVerticalScalingSchedulerPreemption 特性门控，使用 Kubernetes v1.37 镜像创建集群。部署低优先级（3 CPU）和高优先级（4 CPU）Pod 占满 7/8 CPU，然后 patch 高优先级 Pod 将 CPU 请求增至 6，观察调度器抢占低优先级 Pod 并完成扩容。
