介绍 Node Readiness Controller
发布: (2026年2月3日 GMT+8 10:00)
4 min read
原文: Kubernetes Blog
Source: Kubernetes Blog
为什么需要 Node Readiness Controller？
核心 Kubernetes 节点的 Ready 状态往往不足以满足具有复杂引导需求的集群。运维人员经常难以确保特定 DaemonSet 或本地服务在节点进入调度池之前已健康。
Node Readiness Controller 通过允许运维人员为特定节点组定义自定义调度门来填补这一空白。这使您能够在异构集群中强制执行不同的就绪要求，例如：
- 配备 GPU 的节点 在专用驱动验证通过后才接受 Pod。
- 通用节点 按照标准流程。
主要优势
- 自定义就绪定义 – 为您的平台定义“就绪”的含义。
- 自动污点管理 – 控制器根据条件状态自动添加或移除节点污点，防止 Pod 落在未就绪的基础设施上。
- 声明式节点引导 – 可靠地管理多步骤节点初始化，并对引导过程提供清晰的可观测性。
核心概念和特性
控制器围绕 NodeReadinessRule (NRR) API 构建，允许你为节点声明门控条件。
灵活的执行模式
| 模式 | 描述 |
|---|---|
| Continuous enforcement | 在节点整个生命周期内主动维护就绪保证。如果关键依赖（例如设备驱动）在后期出现故障，节点会立即被标记为不可调度，以防止新任务被分配。 |
| Bootstrap‑only enforcement | 适用于一次性初始化步骤（例如预拉取大镜像或硬件供应）。条件满足后，控制器将引导阶段标记为完成，并停止对该节点的特定规则进行监控。 |
条件报告
控制器响应 Node Conditions，而不是自行执行健康检查。这种解耦设计便于与现有工具和自定义方案无缝集成：
- Node Problem Detector (NPD) – 使用已有的 NPD 部署和自定义脚本来报告节点健康。
- Readiness Condition Reporter – 项目提供的轻量级代理，可部署以定期检查本地 HTTP 端点并相应地 patch 节点条件。
干运行（Dry Run）确保运营安全
在整个集群中部署新的就绪规则存在固有风险。Dry‑run 模式 让运维人员在实际执行前模拟影响：
- 控制器记录预期的操作。
- 更新规则状态以显示受影响的节点，但不实际添加污点（taint）。
这使得在正式上线前能够安全地进行验证。
示例：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 – Addressing Non‑Deterministic Scheduling: Introducing the Node Readiness Controller
- GitHub:
- Slack: 加入讨论，使用
#sig-node-readiness-controller - 文档: Getting Started (link to docs)