Presentamos Node Readiness Controller

Por Ajay Sundar Karuppasamy (Google) |
Logotipo de Node Readiness Controller

En el modelo estándar de Kubernetes, que un nodo sea adecuado para ejecutar cargas de trabajo (workloads) depende de una única condición binaria: "Ready". Sin embargo, en los entornos modernos de Kubernetes, los nodos requieren dependencias de infraestructura complejas —tales como agentes de red, drivers de almacenamiento, firmware de GPU o verificaciones de estado (health checks) personalizadas— para estar completamente operativos antes de poder albergar Pods de manera confiable.

Hoy, en nombre del proyecto Kubernetes, me complace anunciar el Node Readiness Controller. Este proyecto introduce un sistema declarativo para gestionar los taints de los nodos, extendiendo las medidas de seguridad de disponibilidad durante el arranque del nodo, más allá de las condiciones estándar. Al gestionar dinámicamente los taints en función de señales de estado personalizadas, el controller garantiza que las cargas de trabajo solo se programen en nodos que cumplan con todos los requisitos específicos de la infraestructura.

¿Por qué el Node Readiness Controller?

El estado principal "Ready" del nodo en Kubernetes a menudo resulta insuficiente para clústeres con requisitos de arranque sofisticados. Los operadores suelen tener dificultades para asegurar que ciertos DaemonSets o servicios locales estén saludables antes de que un nodo entre al grupo de programación.

El Node Readiness Controller resuelve esta brecha al permitir a los operadores definir scheduling gates personalizados y adaptados a grupos de nodes específicos. Esto permite aplicar requisitos de preparación diferenciados a lo largo de clusters heterogéneos; asegurando, por ejemplo, que los nodes equipados con GPU solo acepten pods una vez que se hayan verificado sus drivers especializados, mientras que los nodes de propósito general siguen una ruta estándar.

Ofrece tres ventajas principales:

  • Definiciones de Readiness personalizadas: Define qué significa que un nodo esté listo (ready) para tu plataforma específica.
  • Gestión automatizada de Taints: El controller aplica o elimina automáticamente los taints de los nodos según el estado de sus condiciones, evitando que los Pods caigan en una infraestructura que no está lista.
  • Arranque declarativo de Nodos: Gestiona la inicialización de los nodos en múltiples pasos de forma confiable, aportando una clara observabilidad al proceso de arranque.

Conceptos clave y características

El controller se basa en la API NodeReadinessRule (NRR), la cual permite definir Gates declarativos para tus nodos.

Modos de aplicación flexibles

El controller admite dos modos operativos distintos:

Continuous enforcement (Aplicación continua)
Mantiene activamente la garantía de preparación (readiness) a lo largo de todo el ciclo de vida del node. Si una dependencia crítica (como el driver de un dispositivo) falla más adelante, el node se marca inmediatamente con un taint para evitar un nuevo scheduling.
Bootstrap-only enforcement (Aplicación solo en bootstrap)
Específico para los pasos de inicialización que ocurren una sola vez, como la descarga previa (pre-pulling) de imágenes pesadas o el aprovisionamiento de hardware. Una vez que se cumplen las condiciones, el controller marca el bootstrap como completado y deja de monitorear esa regla específica para dicho node.

Reporte de condiciones

El controller reacciona a las condiciones del nodo (Node Conditions) en lugar de realizar las verificaciones de estado por sí mismo. Este diseño desacoplado le permite integrarse sin problemas con otras herramientas del ecosistema, así como con soluciones personalizadas:

  • Node Problem Detector (NPD): Utiliza tus configuraciones existentes de NPD y scripts personalizados para reportar el estado del nodo.
  • Readiness Condition Reporter: Un agente ligero provisto por el proyecto que puede desplegarse para realizar comprobaciones periódicas en endpoints HTTP locales y actualizar las condiciones del nodo según corresponda.

Seguridad operativa con Dry Run

Desplegar nuevas reglas de preparación a lo largo de una flota de nodos conlleva un riesgo inherente. Para mitigarlo, el modo dry run permite a los operadores simular primero el impacto en el cluster. En este modo, el controller registra las acciones previstas y actualiza el estado (status) de la regla para mostrar los nodes afectados sin aplicar los taints reales, lo que permite una validación segura antes de su aplicación definitiva.

Ejemplo: Bootstrapping de CNI

El siguiente NodeReadinessRule garantiza que un nodo permanezca no programable (unschedulable) hasta que su agente CNI sea funcional. El controller monitorea una condición personalizada cniplugin.example.net/NetworkReady y solo remueve el taint readiness.k8s.io/acme.com/network-unavailable una vez que el estado es True.

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: ""

Demostración:

Participa en la comunidad

El Node Readiness Controller apenas está comenzando, con nuestros lanzamientos iniciales ya disponibles, y estamos buscando comentarios de la comunidad para perfeccionar nuestro mapa de ruta (roadmap). Tras nuestras productivas discusiones en el Unconference de KubeCon NA 2025, estamos entusiasmados por continuar la conversación en persona.

Acompáñanos en KubeCon + CloudNativeCon Europe 2026 en nuestra sesión del maintainer track: Addressing Non-Deterministic Scheduling: Introducing the Node Readiness Controller.

Mientras tanto, puedes contribuir o seguir nuestro progreso aquí: