Kubernetes Blog

Presentamos Node Readiness Controller

Tue, 03 Feb 2026 10:00:00 +0800

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

GitHub: https://sigs.k8s.io/node-readiness-controller
Slack: Únete a la conversación en #sig-node-readiness-controller
Documentación: Guía de inicio

Gateway API v0.8.0: Soporte para service mesh

Tue, 29 Aug 2023 10:00:00 -0800

Autores: Flynn (Buoyant), John Howard (Google), Keith Mattix (Microsoft), Michael Beaumont (Kong), Mike Morris (independent), Rob Scott (Google). Traducción desde el inglés (y errores relacionados) por Flynn.

¡Mil gracias a María Teresa Rojas y Dani Baeyens por su inestimable ayuda revisando este post!

Es un gran placer anunciar la versión v0.8.0 de Gateway API. Con esta versión, el soporte para service mesh en Gateway API ha alcanzado el estado Experimental. ¡Esperamos tus comentarios en la nueva versión!

Además, nos alegra anunciar que Kuma 2.3+, Linkerd 2.14+ e Istio 1.16+ cumplen completamente con el soporte de service mesh de Gateway API.

Nota: "Gateway API" es un nombre propio de esta API.

Soporte para service mesh en Gateway API

Aunque el foco inicial de Gateway API siempre fue el tráfico de entrada al cluster (norte-sur), estaba claro casi desde el principio que los mismos conceptos básicos de enrutamiento también deberían aplicarse al tráfico de service mesh (este-oeste). En 2022, el subproyecto Gateway API lanzó la iniciativa GAMMA, un flujo de trabajo independiente a los distintos proveedores, para examinar la mejor manera de adaptar el soporte de service mesh al marco de los recursos de Gateway API, sin hacer que los usuarios de Gateway API tuvieran que aprender de nuevo todo lo aprendido.

Durante el último año, GAMMA ha investigado con cuidado los desafíos y posibles soluciones para usar Gateway API para service mesh. El resultado final son unas pocas propuestas de mejora que reflejan muchas horas de reflexión y debate, y proporcionan un camino viable, con cambios mínimos, para permitir que Gateway API soporte service mesh.

¿Cómo funcionará el enrutamiento de mesh con Gateway API?

Todos los detalles se puede encontrar en la documentación de la mesh de Gateway API y en GEP-1426, pero en resumen: en Gateway API v0.8.0, un HTTPRoute puede tener un parentRef que sea un Service, no solo un Gateway. Anticipamos GEPs futuros en esta área a medida que adquirimos más experiencia con los casos de uso de service mesh: la capacidad de asociar un HTTPRoute con un Service permite usar Gateway API para una service mesh, pero hay múltiples casos de uso interesantes que son difíciles de manejar.

Un ejemplo: podrías usar un HTTPRoute para hacer una prueba A-B con la service mesh así:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: bar-route
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: demo-app
    port: 5000
  rules:
  - matches:
    - headers:
      - type: Exact
        name: env
        value: v1
    backendRefs:
    - name: demo-app-v1
      port: 5000
  - backendRefs:
    - name: demo-app-v2
      port: 5000

Cualquier solicitud al puerto 5000 del Service demo-app que tenga la cabecera env: v1 se dirigirá a demo-app-v1, y las que no la tengan se dirigirán a demo-app-v2. Dado que esta decisión la toma la service mesh en vez del controlador de ingress, la prueba A-B se puede realizar en cualquier nivel del gráfico de llamadas de la aplicación.

¿Cómo se puede confiar que este soporte será verdaderamente portátil?

Gateway API ha invertido mucho esfuerzo en pruebas de conformidad en todas las funciones que soporta, y las de la service mesh no son excepciones. Uno de los desafíos que enfrentó la iniciativa GAMMA fue que muchas de estas pruebas siempre han requerido que la implementación proporcionara un controlador de ingress. Muchas service meshes no hacen así, y requerir que una mesh implemente un controlador de ingress para cumplir con GAMMA no parece práctico, cuando menos. Por lo tanto, hemos reiniciado el trabajo en perfiles de conformidad de Gateway API, como se describe en GEP-1709.

Con perfiles de conformidad, podemos definir subconjuntos de la funcionalidad de Gateway API, y permitir que las implementaciones elijan (y documenten) a qué subconjuntos se ajustan. GAMMA agrega un nuevo perfil Mesh, descrito en GEP-1686, que sólo verifica la funcionalidad de service mesh definida por GAMMA. Ahora mismo, Kuma 2.3+, Linkerd 2.14+ e Istio 1.16+ son completamente compatibles con el perfil Mesh.

¿Qué más hay en Gateway API v0.8.0?

Ésta versión trata principalmente de preparar Gateway API para la versión v.1.0, en la que planeamos que HTTPRoute, Gateway y GatewayClass se graduarán a GA. Hay dos cambios principales relacionados con esta preparación: validación CEL y cambios en la versión de la API.

Validación CEL

Gateway API v0.8.0 comienza la transición desde validación por webhook hasta validación CEL, usando información incluida en los CRDs. Esta transición significa cosas diferentes dependiendo de la versión de Kubernetes que se use:

Kubernetes 1.25+

La validación CEL está completamente soportada, y casi toda la validación de Gateway API está implementada en CEL. La única excepción es que, en los filtros de modificación de cabeceras, CEL solo puede validar los nombres de las cabeceras sin distinguir entre mayúsculas y minúsculas. Hay más información en #2277.

Recomendamos que no uses el webhook de validación en estas versiones de Kubernetes.

Kubernetes 1.23 y 1.24

La validación CEL no está soportada, pero aún se puede instalar los CRDs de Gateway API v0.8.0. Cuando actualices a Kubernetes 1.25+, la validación CEL incluida en los CRDs se activará automáticamente.

Recomendamos que sigas usando el webhook de validación en estas versiones de Kubernetes.

Kubernetes 1.22 y versiones anteriores

Gateway API solo se compromete a admitir las cinco versiones más recientes de Kubernetes. Por lo tanto, estas versiones ya no están soportados por Gateway API, y la versión v0.8.0 no se puede instalar en ellas (porque los CRDs que contengan validación CEL serán rechazados).

Cambios en la versión de la API

En la versión de Gateway API v1.0, se graduarán los recursos Gateway, GatewayClass y HTTPRoute a la versión de API v1 desde v1beta1. Como preparación, seguimos actualizando las versiones de los recursos que se han graduado desde la versión v1alpha1 a v1beta1. Para más información, consulta las notas de lanzamiento de la versión v0.8.0.

Cómo empezar con Gateway API

Gateway API representa el futuro de las APIs de load balancing, enrutamiento y service mesh en Kubernetes. Ya hay mas que 20 implementaciones disponibles (incluidos controlodores de ingress y service meshes) y este número siempre está creciendo.

Si tienes interés en Gateway API, te recomendamos empezar con la documentación oficial sobre conceptos de la API. Además, las Guías cubren la instalación y configuración de Gateway API, y demuestran cómo usar Gateway API para lograr varios casos de uso comunes. Dado que esta API se basa en CRDs, puedes instalar la última versión en cualquier cluster de Kubernetes 1.23+.

Si tienes ganas de contribuir a Gateway API, ¡nos alegra saberlo! Por favor no tengas dudas en crear un nuevo issue en nuestro repositorio de GitHub o unirte a las discusiones. Además puedes consultar la página de la comunidad, que tiene enlaces a Slack e información sobre nuestras reuniones comunitarias cada dos semanas.

Gracias por tu continuo apoyo y comentarios sobre Gateway API. Estamos emocionados de ver cómo usas esta API en producción y esperamos escuchar sobre tus experiencias.

Leer más

GEP-1324 proporciona una descripción general de los objetivos de GAMMA y algunas definiciones importantes. Leer este GEP vale la pena por su tratamiento del espacio del problema.
GEP-1426 define cómo usar Gateway API recursos de enrutamiento (p.e. HTTPRoute) para manejar tráfico en una service mesh.
GEP-1686 se basa en el trabajo del GEP-1709 y define un perfil de conformidad para que una service mesh se declare conforme con Gateway API.

Aunque estos patrones están en Experimental, están disponibles en el canal standard, porque la iniciativa GAMMA no ha necesito agregar nuevos recursos o campos hasta ahora.