Antes de reiniciar un nodo Kubernetes: PDB, drenado y recuperación

Qué hace el drenado y qué no garantiza

kubectl drain marca un nodo como no programable y solicita evacuar sus Pods antes de mantenimiento. Cuando el servidor admite la Eviction API, las evacuaciones respetan los PodDisruptionBudgets (PDB) y el período de terminación configurado. Un PDB limita ciertas interrupciones voluntarias; no garantiza que la aplicación siga respondiendo ni que los Pods reemplazo puedan programarse.

Este procedimiento sirve para preparar un cambio aprobado. No se ha ejecutado contra un clúster real y no reemplaza las instrucciones de tu distribución o proveedor. Antes de empezar, confirma el contexto dekubectl, las versiones, la ventana, la capacidad de recuperación y quién puede detener el cambio.

1. Confirma contexto, nodo y cargas

Ejecuta primero consultas de lectura. Guarda las salidas en el registro operativo autorizado, no en un ticket público: pueden incluir nombres de nodos, namespaces, etiquetas y otros datos de la organización.

kubectl config current-context
kubectl version
kubectl get nodes -o wide

NODE='<nombre-confirmado-del-nodo>'
kubectl get node "$NODE" -o wide
kubectl describe node "$NODE"
kubectl get pods -A --field-selector "spec.nodeName=${NODE}" -o wide
kubectl get pdb -A

Revisa qué controlador administra cada Pod y si existen réplicas sanas fuera del nodo. Identifica los Pods de DaemonSet, las cargas sin controlador y los volúmenes locales. Revisa cada PDB: selector, disponibilidad actual, disponibilidad deseada e interrupciones permitidas. Un selector equivocado puede dejar una aplicación sin protección.

2. Confirma que el resto del clúster puede recibir las cargas

Antes de evacuar, revisa solicitudes y límites de CPU y memoria, capacidad libre, taints y tolerations, afinidad, distribución entre zonas, acceso a volúmenes y restricciones del proveedor. El presupuesto de interrupción no crea capacidad: un Pod puede quedar Pendingaunque el drenado haya respetado el PDB.

Trata emptyDir como datos locales que pueden perderse cuando el Pod se elimina. Define con su responsable si son descartables antes de usar una opción que permita borrar esos Pods. Los Pods gestionados por un DaemonSet normalmente permanecen en el nodo; el controlador volvería a crearlos allí aunque estuviera marcado como no programable.

Un PDB limita evacuaciones que pasan por la API correspondiente. No protege todas las acciones: borrar directamente un Deployment o eliminar manualmente un Pod puede eludirlo. Si un presupuesto bloquea el cambio, detente y averigua la causa; no desactives el control para completar la ventana.

3. Drena un solo nodo y observa el resultado

Para nodos con Pods de DaemonSet, Kubernetes documenta--ignore-daemonsets. La opción permite continuar sin borrar esos Pods. El tiempo de 15 minutos siguiente es un ejemplo; ajústalo al procedimiento aprobado y a los períodos de terminación de tus cargas.

kubectl drain "$NODE" --ignore-daemonsets --timeout=15m

Drena un nodo por vez. Si el comando espera o falla, revisa el motivo, los eventos, el estado de las réplicas y disruptionsAlloweden el PDB. Espera a que la aplicación recupere salud o corrige la capacidad y restricciones de destino antes de reintentar.

No uses --disable-eviction para sortear el PDB: fuerza el borrado y omite su comprobación. No añadas --delete-emptydir-datasin aceptar la pérdida de esos datos. Si aparece un Pod sin controlador, investiga quién lo administra y cuál es el plan de recuperación antes de autorizar --force.

4. Mantén el nodo fuera de servicio hasta verificarlo

Empieza el mantenimiento del sistema operativo o del proveedor solo después de que el drenado termine correctamente. Tras la intervención, confirma que el nodo está Ready y que los servicios básicos operan antes de permitir nuevas cargas.

kubectl get node "$NODE" -o wide
kubectl uncordon "$NODE"
kubectl get nodes -o wide
kubectl get pods -A -o wide

uncordon habilita de nuevo la programación en el nodo; no demuestra que la aplicación funciona. Comprueba las réplicas y el recorrido real del servicio con los controles aprobados por el equipo. Si el nodo no vuelve a Ready, mantenlo fuera de servicio y sigue el plan de recuperación de la plataforma.

Para completar la preparación, relaciona este procedimiento con la guía de respaldo y restauración en Kubernetes y el checklist de cambios operativos de la versión que corresponda a tu clúster.

El PDB es una barrera; la disponibilidad se verifica aparte

Una evacuación permitida solo indica que Kubernetes aceptó esa interrupción según las reglas aplicables. Réplicas sanas, capacidad de destino, almacenamiento y pruebas del servicio determinan si el cambio puede completarse con el nivel de operación esperado. Revisa los cambios operativos de Kubernetes y solicita una revisión antes de mover nodos que sostienen cargas críticas.