元鉴
返回中文阅读流

Kubernetes Blog

介绍 Node Readiness Controller

在标准的 Kubernetes 模型中,节点对工作负载的适用性取决于单一的二元“Ready”条件。然而,在现代 Kubernetes 环境中,节点需要复杂的底层基础设施依赖——例如网络代理、存储驱动、GPU 固件或自定义健康检查——才能完全正常运行,从而可靠地托管 Pod。今天,代表 Kubernetes 项目,我宣布推出 Node Readiness Controller。该项目引入了一种用于管理节点污点(taints)的声明式系统,将节点引导期间的就绪护栏扩展至标准条件之外。

中文内容

已翻译official company source英文原文2026-02-03

介绍 Node Readiness Controller

By Ajay Sundar Karuppasamy (Google) | Tuesday, February 03, 2026
Logo for node readiness controller

在标准的 Kubernetes 模型中,节点是否适合承载工作负载取决于二元的“Ready(就绪)”状态。然而,在现代 Kubernetes 环境中,节点必须满足复杂的底层基础设施依赖——例如网络代理、存储驱动、GPU 固件或自定义健康检查——完全运行正常后,才能可靠地托管 Pod。

今天,我代表 Kubernetes 项目正式宣布推出 Node Readiness Controller。该项目引入了一套用于管理节点污点的声明式系统,将节点引导期间的就绪防护边界扩展到了标准条件之外。通过基于自定义健康信号动态管理污点,该控制器确保工作负载仅被调度至满足所有特定基础设施要求的节点上。

为什么需要 Node Readiness Controller?

对于引导流程复杂的集群,Kubernetes 原生的节点“Ready”状态往往不足以满足需求。运维人员常常难以确保在节点加入调度池之前,特定的 DaemonSet 或本地服务已处于健康状态。

Node Readiness Controller 填补了这一空白,允许运维人员为特定节点组定义自定义调度门控。这使得您能够在异构集群中实施差异化的就绪要求,例如,确保搭载 GPU 的节点仅在专用驱动验证通过后才接收 Pod,而通用节点则沿用标准路径。

它提供了三大主要优势:

  • 自定义就绪定义:为您特定的平台定义“就绪”的具体含义。
  • 自动化污点管理:控制器根据条件状态自动添加或移除节点污点,防止 Pod 调度到未就绪的基础设施上。
  • 声明式节点引导:可靠地管理多步骤节点初始化,并对引导过程提供清晰的可观测性。

核心概念与特性

该控制器以 NodeReadinessRule (NRR) API 为核心,允许您为节点定义声明式门控条件。

灵活的执行模式

控制器支持两种截然不同的运行模式:

Continuous enforcementActively maintains the readiness guarantee throughout the node’s entire lifecycle. If a critical dependency (like a device driver) fails later, the node is immediately tainted to prevent new scheduling.Bootstrap-only enforcementSpecifically for one-time initialization steps, such as pre-pulling heavy images or hardware provisioning. Once conditions are met, the controller marks the bootstrap as complete and stops monitoring that specific rule for the node.

条件上报

控制器响应节点条件而非自行执行健康检查。这种解耦设计使其能够与生态系统中现有的其他工具及自定义解决方案无缝集成:

  • Node Problem Detector (NPD):利用现有的 NPD 配置和自定义脚本来报告节点健康状况。
  • Readiness Condition Reporter:该项目提供的一个轻量级代理,可部署用于定期检查本地 HTTP 端点,并据此更新节点条件。

通过 dry run 模式保障操作安全

在集群中部署新的就绪规则存在固有风险。为降低此风险,dry run 模式允许操作员首先模拟其对集群的影响。在此模式下,控制器将记录预期操作并更新规则状态以显示受影响的节点,而不会实际施加污点,从而在正式生效前实现安全验证。

示例:CNI 初始化

以下 NodeReadinessRule 可确保节点在其 CNI 代理正常运行之前保持不可调度状态。控制器会监控自定义的 cniplugin.example.net/NetworkReady 条件,并且仅当该状态为 True 时,才会移除 readiness.k8s.io/acme.com/network-unavailable 污点。

apiVersion: readiness.node.x-k8s.io/v1alpha1
kind: NodeReadinessRule
metadata:
  name: network-readiness-rule
spec:
  conditions:
    - type: "cniplugin.example.net/NetworkReady"
      requiredStatus: "True"
  taint:
    key: "readiness.k8s.io/acme.com/network-unavailable"
    effect: "NoSchedule"
    value: "pending"
  enforcementMode: "bootstrap-only"
  nodeSelector:
    matchLabels:
      node-role.kubernetes.io/worker: ""

演示:

参与项目

Node Readiness Controller 项目才刚刚起步,初始版本已发布,我们正在征求社区反馈以完善项目路线图。继在 KubeCon NA 2025 进行了富有成效的 Unconference 讨论后,我们非常期待能在线下继续交流。

欢迎参加 KubeCon + CloudNativeCon Europe 2026 的维护者专场会议:应对非确定性调度:介绍 Node Readiness Controller。

在此期间,您可以通过以下渠道参与贡献或跟踪我们的进展:

  • 正文:GitHub:https://sigs.k8s.io/node-readiness-controller
  • Slack:在 #sig-node-readiness-controller 频道加入讨论
  • 文档:入门指南
  • 下一页 →
Last modified April 22, 2026 at 9:24 PM PST: Clean up blog article paths (0d8c0e7ad2)

原文标题

Introducing Node Readiness Controller