Kubernetes项目最近宣布了一个名为节点就绪控制器（Node Readiness Controller）的新核心控制器，旨在通过使 API 服务器对节点就绪状态的视图更加准确，从而增强调度的可靠性和集群健康。这个特性目前处于 alpha 阶段，它解决了长期以来的问题，即在 kubelet 已经将节点标记为不可用的情况下，仍然将 pod 调度到这些节点上，这有助于防止不必要的 pod 驱逐，并提高整体工作负载的稳定性。
在大型动态集群中，节点的瞬时不可用性，比如 kubelet 和 API 服务器之间的短暂网络中断，可能会导致过时的就绪信息持续存在。这种过时状态历史上导致调度器错误地认为节点是健康的，而实际上并非如此，结果就是将 pod 放置在无法可靠启动或运行工作负载的节点上。节点就绪控制器通过直接从 kubelet 协调节点就绪信号，并通过对 API 服务器暴露一致的、权威的状态来填补这一空白。
新的控制器建立在 Kubernetes 现有的就绪机制之上，但引入了一个专门的控制循环，确保 API 服务器的节点条件反映了最新和最准确的健康信号。在实践中，这意味着 pod 不太可能被调度到经历瞬时故障的节点上，操作者可以更有信心地认为调度决策是基于最新的节点状态。博客文章概述了控制器如何观察 NodeReady 条件，并将 kubelet 报告的就绪状态以减少的延迟和提高的一致性传播到中央控制平面。
该公告还澄清了节点就绪控制器如何与相关的功能如污点和容忍度、Pod 中断预算（Pod Disruption Budgets，PDBs）和集群自动伸缩器的交互。通过使 API 服务器状态与实际节点就绪状态对齐，预计该特性将减少不必要的扩展/启动，并最小化由过时条件触发的破坏性驱逐。这不仅改善了开发者体验，还减少了成本和在状态频繁波动的环境中的操作噪音。
节点就绪不一致性一直是许多 Kubernetes 部署中的一个微妙但持续存在的痛点，尤其是在大规模部署中。在此发布之前，运维人员经常诉诸于自定义脚本、外部健康检查或手动调整就绪门来避免不希望的调度结果。通过将这种逻辑编码到核心控制平面中，Kubernetes 旨在简化集群操作并减少对定制解决方案的需求。
社区贡献者已经开始尝试这个 alpha 特性，早期反馈表明它可能显著提高在网络闪断频繁或工作负载高度弹性的集群中的调度保真度。随着使用经验的增长，该特性将继续通过 Kubernetes 增强流程发展，并计划在不同环境中验证稳定性和操作人体工程学后升级到 beta。
与市场上的其他方法相比，如围绕集群引导的自定义脚本或增强调度行为的第三方控制器，节点就绪控制器的声明式 API（NodeReadinessRule）和与 Kubernetes 调度机制的原生集成使其成为异构环境中更系统和更可扩展的解决方案。传统的系统和更简单的编排平台通常缺乏这种可插拔的就绪控制水平，通常需要定制工具或外部编排层来实现类似的保证。此外，尽管许多商业管理的 Kubernetes 服务专注于自动化维护和升级，但它们并不内在地提供与此控制器引入的基础设施感知引导逻辑相同的水平。通过这样做，Kubernetes 继续向更细粒度的操作安全和直接构建在其核心抽象中的可扩展性发展。
节点就绪控制器突出了 Kubernetes 演进中的一个更广泛的主题：加强控制平面的一致性，确保编排决策反映集群的真实状态，减少开发者和操作者的意外。对于在大规模运行关键工作负载的组织来说，这次更新代表了向更可靠、可预测的调度行为迈出的关键一步。
原文链接：
https://www.infoq.com/news/2026/02/kubernetes-node-readiness/
