云原生 Kubernetes 1.34 调度变化 怎样处理

面对 Kubernetes 1.34 的调度变化，先不要把 Pending 全部归因于新版本。需要优先弄清的是：Pod 为什么被拒绝，集群发生了什么变化，以及这次变化是否值得让它重新尝试。重新入队更精准，并不意味着集群突然有了更多 CPU、可用存储或符合亲和性的节点。

本文是对 1.34 历史版本的运维梳理，不将它作为当前最新版本推荐。官方发布说明入口可复制访问：https://kubernetes.io/blog/2025/08/27/kubernetes-v1-34-release/。讨论集中在 QueueingHint，不展开其他版本的新调度功能。

一、先确认变化发生在哪个环节

1.34 将 QueueingHint 标为稳定、默认启用。它让插件依据集群事件判断：此前被拒绝的 Pod 是否值得重新排队。判断认为事件可能有帮助时，Pod 可以进入活跃队列或退避队列，等待调度器再次尝试。这不是对最终节点选择的承诺。

官方发布说明把这项改进归入更高效的重新入队。它的意义在于减少无关事件造成的无效重试；部分插件还可以在安全条件下跳过通常的退避。不能据此写成“所有 Pending Pod 都会立即重试”，更不能把它解释成关闭过滤条件。

对已有应用而言，处理重点应从“给所有 Pod 加一个新字段”转为“核对失败原因与重试触发是否匹配”。没有业务需求时，不应为追求版本特性而改写工作负载约束。

二、把资源不足与重新入队分开

设想一个示例环境：一类任务需要较多内存，另一类任务受节点标签限制。它们都可能暂时不能调度，但修复动作不同。释放其他节点上的内存，未必能帮助被标签条件挡住的任务；更新一个与筛选无关的注解，也不能当然解决内存缺口。这只是说明边界的假设场景，不是实测案例。

建议为待处理问题保留三项记录：当时的拒绝原因、对应资源或对象、发生变化后希望重新考虑的条件。先检查这些信息，再决定是扩容、调整合理的请求值，还是修复错误的亲和性配置。不要为了让队列动起来就盲目降低 requests，应用的真实资源需求仍然存在。

三、区分使用默认调度器和维护自定义插件

如果团队只使用默认配置，应优先整理 scheduler 版本、工作负载的 schedulerName、已有调度配置及安装方式。不要把“控制面版本已更新”当作所有自定义调度器镜像也同步更新的证据。不同调度器承担的任务要分别归属，避免把另一套调度器处理的 Pod 混入比较。

如果维护自定义插件，则要另外梳理插件拒绝 Pod 的条件与订阅事件。1.34 框架文档将 EnqueueExtension 描述为控制被拒绝 Pod 重试的接口，并指出若干扩展点的插件应实现它。插件作者需要基于目标版本接口审视实现，而不是只修改镜像标签。

建议建立一份内部对应表：哪个条件会拒绝、哪个对象变化可能解除条件、哪些变化无关。这个表用于插件维护和迁移讨论，不应假装仅凭一张表就能证明实现正确。本文不提供脱离实际插件源码的通用补丁。

四、观察结果要拆成三层

第一层看队列：失败的工作负载有没有得到合理的再次尝试机会，是否仍在等待。第二层看绑定：是否选到了符合要求的节点并完成绑定。第三层看运行：镜像拉取、容器启动及业务就绪是否正常。三层问题不能互相代替。

例如，Pod 已绑定后镜像拉取失败，继续调整重新入队策略通常找错了方向。反过来，Pod 仍因约束没有可用节点，也不能仅凭调度器整体 CPU 下降就宣布问题解决。判断时要把等待时间、失败原因和最终归宿放在同一个工作负载背景下理解。

建议迁移记录采用相同的观察窗口，注明负载规模、节点资源和配置差异。只报告排队次数或平均值容易掩盖少量长期等待的任务；保留最慢一组任务的具体约束，有助于避免总体指标好看却个别任务受损。这里是记录建议，不包含性能收益承诺。

五、围绕代表性约束安排迁移

迁移范围应包含团队真正使用的约束，而非只放一个无特殊要求的小 Pod。可按资源请求较大、亲和性要求明确、依赖存储、使用自定义调度器等类型整理代表性清单；未使用的能力不必为了凑项目而启用。

每一类先写清预期：资源不满足时应继续等待，相关条件恢复后应有机会重新考虑，仍不满足其他约束时不应被强行安置。不要将“修改无关字段也没有立即重试”直接归为故障，因为减少无效尝试正是这一机制希望达到的效果。

扩展迁移时按调度器配置和工作负载类型逐步推进，避免同时修改请求值、亲和性、插件与节点规模。变量一起变化后，即使结果改善，也难以判断来自版本变化还是业务配置调整。

六、回退围绕故障证据，不围绕版本印象

保留升级前配置、镜像标识、插件构建来源和已知工作负载约束。若出现持续无法重新考虑的任务，优先记录具体拒绝条件、相关对象变化及调度器归属，再按团队既有升级与回退方案处理。不要把删除重建 Pod 当作长期解决办法，它可能打断任务并抹去分析线索。

回退也不等于随意降级控制面组件；应遵循集群发行版的兼容与恢复安排，尤其注意自定义插件和配置之间的对应关系。没有明确兼容说明时，不在生产环境临时拼接组件版本。

最终处理原则可以压缩成一句话：把 1.34 的重新入队改进当作减少无效调度工作的机制，把资源、亲和性和存储当作仍需满足的现实条件。先把问题放回正确的一层，再选择扩容、修正约束或处理插件适配。

参考：Kubernetes 1.34 官方发布说明；1.34 调度框架版本文档。后者为静态历史文档，适合核对本文讨论的版本边界。