Kubernetes 1.37: condiciones del ciclo de vida del nodo

Una señal común para eventos del nodo

Durante una ventana de mantenimiento, distintas herramientas necesitan entender si un nodo se está drenando, ya cumplió los criterios definidos para el drenado o está en reparación. Hasta ahora, cada controlador podía deducirlo de señales distintas, como disponibilidad, taints, Pods o etiquetas. Kubernetes 1.37 incorpora tipos conocidos de condición para publicar ese contexto en el estado del objeto Node.

Estas condiciones son observaciones compartidas. Por sí solas no impiden que se programen Pods, no evacuan cargas y no garantizan que una aplicación conserve su disponibilidad. Su valor está en ofrecer un estado legible para operadores, paneles y automatizaciones que decidan consumirlo.

Las cinco condiciones definidas

• DrainInProgress: el administrador o automatización está ejecutando el drenado con los criterios que eligió.
• Drained: el nodo alcanzó esos criterios. No significa que toda carga imaginable esté ausente; depende de cómo el operador definió que el drenado está completo.
• MaintenancePlanned: se prevé un cambio futuro en el nodo.
• MaintenanceInProgress: el nodo está en mantenimiento, reparación, actualización o retiro.
• GracefulNodeShutdownInProgress: se observa un apagado ordenado del nodo en curso.

Cada condición informa True, False o Unknown. También puede incluir un reason estable y legible por máquina, un message explicativo y el momento de transición. El mensaje ayuda a la operación, pero no sustituye un registro de cambio con responsable, ventana, alcance y resultado.

Qué cambia en 1.37 y qué sigue igual

El anuncio de 1.37 describe NodeLifecycleConditions como una función Alpha, desactivada por defecto. Para esta versión, el gate no restringe quién puede escribir las condiciones y ningún controlador central las consume para cambiar su conducta. El administrador o un controlador autorizado debe publicar y limpiar cada señal. La documentación oficial también indica que el gate debe habilitarse en los componentes pertinentes cuando se adopte la función; confirma el comportamiento de tu distribución y versión antes de depender de ella.

Conserva los mecanismos que ya gobiernan el ciclo operativo: usa el cordón para impedir programación normal, kubectl drain para solicitar evacuaciones y taints/tolerations cuando necesites controlar programación o expulsión. Los PDB limitan ciertas interrupciones voluntarias, pero no crean capacidad ni aseguran que los Pods de reemplazo queden listos.

Para la secuencia de verificación antes de un reinicio, consulta la guía de drenado, PDB y recuperación. No uses una condición como sustituto de revisar réplicas, almacenamiento, capacidad y el estado de la aplicación.

Consulta las condiciones antes de intervenir

Estos comandos consultan el estado reportado por la API. Requieren permiso de lectura sobre los nodos; los nombres pueden revelar información de la infraestructura, así que conserva la salida en el sistema interno autorizado.

NODE='<nombre-confirmado-del-nodo>'

# Muestra condiciones y eventos asociados al nodo.
kubectl describe node "$NODE"

# Imprime el tipo y el estado de cada condición.
kubectl get node "$NODE" \
  -o jsonpath='{range .status.conditions[*]}{.type}={.status}{"\n"}{end}'

La salida por sí sola no confirma que exista una ventana aprobada ni que el nodo pueda salir de servicio. Compara las señales con la orden de cambio, los PDB, las cargas ubicadas en el nodo y la herramienta que administra el ciclo. Si una condición queda activa después del trabajo, confirma quién es su escritor y cómo se limpia; un estado obsoleto puede confundir a quien opere después.

Define quién escribe cada estado

Kubernetes no establece propiedad exclusiva, bloqueo ni transferencia entre escritores. Antes de integrar estas señales, asigna un único dueño operativo por condición: por ejemplo, el controlador de mantenimiento puede anunciar planificación e inicio, mientras que la automatización de drenado publica el comienzo y el cumplimiento de sus criterios. Define además qué ocurre si el controlador se detiene, el trabajo se cancela o cambia el responsable.

Una adopción prudente empieza en un clúster de prueba o en modo de observación. Comprueba quién actualiza el estado, si el historial es suficiente para investigar y si las herramientas lo muestran sin confundirlo con Ready o con la condiciónSchedulingDisabled. Solo integra consumidores después de validar su versión y su respuesta ante condiciones ausentes, antiguas o contradictorias.

Para revisar un clúster, documenta primero la versión, los controladores de mantenimiento, el flujo de drenado y las reglas de acceso. La guía general de cambios de Kubernetes 1.37 reúne otros puntos de compatibilidad que conviene incluir en el inventario.