Mantenimiento de nodos

Introducción

En un entorno de producción de Kubernetes, a menudo es necesario realizar tareas de mantenimiento en los nodos. El desafío consiste en hacerlo sin causar interrupciones innecesarias en las cargas de trabajo.

Imagine que el nodo es una habitación de hotel y que los pods son los huéspedes. Si necesita renovar la habitación (realizar tareas de mantenimiento), no puede entrar sin más mientras los huéspedes duermen. Necesita seguir un proceso seguro y considerado.

En este laboratorio, aprenderá el flujo de trabajo estándar para realizar el mantenimiento de un nodo:

• Cordon (No molestar): Coloque en la puerta un letrero que diga «No se admiten nuevos huéspedes». El hotel (el planificador) deja de enviar nuevas personas a esta habitación.
• Drain (Desalojar): Pida amablemente a los huéspedes actuales que se marchen y trasládelos a otra habitación disponible.
• Mantenimiento: Realice el trabajo necesario (la renovación).
• Uncordon (Reabrir): Retire el letrero y permita de nuevo la programación.

Trabajará con un clúster local de Minikube para simular este proceso.

Marcar el nodo como no programable

Antes de realizar cualquier tarea de mantenimiento, debemos asegurarnos de que el planificador de Kubernetes no coloque pods nuevos en el nodo en el que vamos a trabajar. Este proceso se denomina «cordoning». Es como colocar en la puerta de la habitación del hotel un letrero de «No molestar» o «Fuera de servicio».

Esta acción afecta a la programación, no apaga el nodo. Un nodo marcado como no programable puede seguir estando en buen estado y ejecutando sus pods existentes. Kubernetes simplemente lo marca como no disponible para nuevas asignaciones, de modo que pueda comenzar el mantenimiento de forma controlada.

Primero, identifique el nombre del nodo. Ejecute el siguiente comando:

kubectl get nodes

Debería aparecer un nodo (por ejemplo, minikube) con el estado Ready.

Para marcar el nodo como no programable, use el comando cordon. Usaremos una sustitución de comandos $() para obtener automáticamente el nombre del nodo:

kubectl cordon $(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')

Ahora, vuelva a comprobar el estado del nodo:

kubectl get nodes

El estado debería cambiar a Ready,SchedulingDisabled. Esto confirma que el nodo está marcado como no programable. No se programarán pods nuevos en este nodo, pero los pods existentes seguirán ejecutándose con normalidad.

Desalojar los pods del nodo

Marcar el nodo como no programable solo detiene la programación de pods nuevos. Todavía tenemos aplicaciones en ejecución (los huéspedes) en la habitación. Para retirarlas de forma segura, usamos el comando drain.

Este comando desaloja los pods. Kubernetes detecta entonces que no se cumple el número deseado de réplicas (2) e intenta crear reemplazos nuevos en otros nodos disponibles.

Aquí es importante la palabra desalojar. El objetivo de drain no es detener los procesos de forma abrupta. Solicita a las cargas de trabajo que se retiren de una manera que tenga en cuenta el funcionamiento de Kubernetes, para que los controladores puedan reemplazarlas y se respeten las reglas de terminación. Por eso drain es más seguro que eliminar manualmente procesos aleatorios del nodo.

Ejecute el comando drain. En este entorno, debemos añadir varias opciones para forzar el desalojo:

• --ignore-daemonsets: Algunos pods del sistema (DaemonSets) están vinculados al nodo y no se pueden mover. Los ignoramos.
• --delete-emptydir-data: Si un pod usa almacenamiento temporal local, el desalojo eliminará esos datos. Aceptamos esta consecuencia.
• --force: Es necesario para eliminar pods que no administra un ReplicationController, ReplicaSet, Job, DaemonSet o StatefulSet, como storage-provisioner en Minikube.

kubectl drain $(kubectl get nodes -o jsonpath='{.items[0].metadata.name}') --ignore-daemonsets --delete-emptydir-data --force

Verá mensajes que indican que los pods están siendo desalojados.

Nota: En este laboratorio de Minikube con un solo nodo, cuando desaloje el único nodo, los pods serán desalojados, pero pasarán al estado Pending. Esto ocurre porque «no hay otras habitaciones en el hotel» a las que puedan trasladarse. En un clúster real con varios nodos, se trasladarían inmediatamente a un nodo en buen estado.

Verificar el estado

Después de desalojar los pods del nodo, es importante verificar qué ocurrió con las aplicaciones.

Este paso de verificación enseña un hábito importante de la administración de clústeres: no se detenga después de emitir un comando de mantenimiento. Inspeccione siempre el resultado de la programación desde el punto de vista de la carga de trabajo. Una acción de mantenimiento solo tiene éxito si las aplicaciones se ejecutan donde corresponde.

Compruebe el estado de los pods:

kubectl get pods

Como se indicó antes, es probable que vea los pods en estado Pending.

Para entender por qué están pendientes, consulte a Kubernetes. Describa uno de los pods:

kubectl describe pod $(kubectl get pods -o jsonpath='{.items[0].metadata.name}')

Busque la sección Events al final de la salida. Debería ver un mensaje similar a «0/1 nodes are available: 1 node(s) are unschedulable.»

Esto confirma que el desalojo se realizó correctamente. El planificador quiere ejecutar el pod, pero respeta el letrero de «No molestar» que colocamos en el único nodo disponible.

Volver a habilitar la programación del nodo

Imagine que ya terminó la «renovación» (la actualización del sistema operativo o las tareas de mantenimiento). Es hora de reabrir la habitación y volver a poner el nodo en servicio.

uncordon simplemente elimina el bloqueo de programación. No obliga a los pods a volver al nodo de inmediato. Indica al planificador que el nodo vuelve a ser elegible para futuras asignaciones; después, la reconciliación normal se encarga del resto.

Para hacerlo, use el comando uncordon. Este comando retira el letrero de «No molestar».

kubectl uncordon $(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')

Ahora, verifique el estado del nodo:

kubectl get nodes

El estado debería volver a ser Ready; la etiqueta SchedulingDisabled ya no debería aparecer.

Por último, vuelva a comprobar los pods. Como el nodo vuelve a estar disponible, el planificador de Kubernetes debería colocar ahora los pods que estaban en estado Pending en este nodo.

kubectl get pods

Debería ver cómo pasan de Pending a ContainerCreating y, finalmente, a Running.

Resumen

En este laboratorio, practicó el ciclo de vida seguro del mantenimiento de un nodo de Kubernetes. Aprendió a:

1. Marcar un nodo como no programable (cordon) para impedir nuevas asignaciones (No molestar).
2. Desalojar los pods de un nodo (drain) para retirar de forma segura las cargas de trabajo en ejecución.
3. Volver a habilitar la programación de un nodo (uncordon) para devolverlo al servicio.

Estos comandos son esenciales para que los administradores de sistemas mantengan una alta disponibilidad. Permiten reparar la infraestructura sin provocar tiempo de inactividad en las aplicaciones (¡por supuesto, en un clúster con varios nodos!).