Cómo drenar nodos en Docker Swarm sin downtime

Contenido del curso

Conceptos básicos

Primeros pasos

Administrando Servicios

Swarm avanzado

Swarm productivo

Conclusiones

24
Escalabilidad con Docker Swarm: listo para millones
00:52 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:007:56

Cómo drenar nodos en Docker Swarm sin downtime

Curso de Swarm

Clase 17 de 24

Clase 17 / 24

Comentarios (13)13 comentarios

José Guillermo

Hace 4 años

DAVID EDUARDO BAEZ SANCHEZ

Hace 6 años

Javier G. Aguilar Melgar

Boris Vargas Paucara

Edwin Garcia

Jonatan Lazo

Edwin Garcia

Oscar Adolfo Vargas López

Hace 4 años

Pablo Aquino

Hace 5 años

Ricardo Etcheto

Hace 6 años

Matias Gabriel Pierri

Hace 6 años

Gonzalo Amador Hernández

Hace 6 años

Gonzalo Amador Hernández

Hace 6 años

Fredy Red Ramos Pomari

Hace 7 años

Fredy Red Ramos Pomari

Hace 7 años

Gonzalo Amador Hernández

Hace 6 años

Usuario anónimo

User

Hace 5 años

Usuario anónimo

User

Hace 6 años

Recursos

Gestionar la disponibilidad de nodos en Docker Swarm permite hacer mantenimiento sin interrumpir el servicio. Aquí verás cómo usar docker node update para poner un nodo en modo drain, confirmar que no hay downtime, y forzar un redeployment para recuperar el equilibrio de réplicas cuando el nodo vuelve a active.

¿Cómo drenar un nodo en Docker Swarm sin downtime?

Poner un nodo en drain evacúa sus tareas y evita que reciba nuevas. Es ideal cuando detectas fallas de conectividad, disco o hardware en un worker y necesitas intervenir sin cortar el servicio.

¿Qué comandos usar para identificar y drenar?

Ver nodos del swarm.

docker node ls

Inspeccionar el nodo con formato legible y revisar su availability.

docker node inspect --pretty <worker-2>

Actualizar el nodo a modo drain para drenar tareas.

docker node update --availability drain <worker-2>

Confirmar el estado.

docker node ls

Consejo: apóyate en el visualizer para observar cómo el scheduler reubica las tareas.

¿Qué efecto tiene en el servicio?

El scheduler saca las tareas del nodo en drain y las mueve a otros nodos disponibles.
Si había, por ejemplo, seis réplicas de una app, pueden concentrarse temporalmente en otro worker.
La respuesta del servicio se mantiene: no hay downtime. Sí puede haber menor throughput durante la rotación de tareas.
Tras el mantenimiento, devuelve el nodo a active.

docker node update --availability active <worker-2>
docker node ls

¿Por qué no se redistribuyen las tareas al reactivar el nodo?

Al volver a active, las tareas pueden seguir donde quedaron. El scheduler de Docker Swarm no reequilibra por sí solo a menos que tenga un motivo claro: un service update, tareas pendientes que no pudo ubicar o la aparición de un nuevo nodo que habilite colocaciones que antes no eran posibles. Si no hay presión de recursos, mantiene el estado estable.

¿Cuándo reprograma el scheduler?

Cuando actualizas el servicio con cambios que requieren recrear tareas.
Cuando existen restricciones y ahora hay un nodo disponible que satisface los constraints.
Cuando hay tareas pendientes y aparece capacidad donde ubicarlas.

Nota: métricas como RAM pueden verse distintas en entornos como Play With Docker respecto del visualizer; guíate por la fuente real del entorno.

¿Cómo forzar un redeployment y rebalancear las réplicas?

Forzar una actualización provoca recreación de tareas y, con ello, que el scheduler vuelva a distribuir entre nodos disponibles. Un truco común es cambiar una variable de entorno que no afecta la lógica del servicio, solo para disparar el redeployment.

¿Qué cambio mínimo dispara la actualización?

Agrega una variable de entorno cualquiera con service update. Para acelerar la demo, se usa paralelismo cero para recrear todo a la vez. aviso: en producción no se recomienda paralelismo 0.

docker service update -d \
  --env-add DUMMY_CHANGE=1 \
  --update-parallelism 0 \
  app

Observa tareas antiguas y nuevas durante la transición.

docker service ps app

Resultado esperado: el scheduler reparte réplicas entre los workers disponibles (por ejemplo, 3 y 3), respetando constraints y priorizando nodos con menor carga.

¿Cómo verificar y limpiar?

Verifica en el visualizer la nueva distribución.
Prueba el endpoint con tus curls: el servicio responde sin interrupciones.
Cuando ya no necesites la app, elimínala.

docker service rm app

Palabras clave y habilidades integradas:

Operación de docker node update para gestionar availability: drain y active.
Uso del scheduler y su comportamiento ante reequilibrio.
Estrategia de service update con variable de entorno para redeployment controlado.
Validación con docker node ls, docker node inspect --pretty y docker service ps.
Consideraciones de throughput y ausencia de downtime durante mantenimiento.

¿Te gustaría compartir cómo planificas el mantenimiento de nodos y qué estrategia de actualización te funciona mejor en tu swarm?

Disponibilidad de un nodo:

active. El nodo trabaja de forma coordinada con el Swarm y puede recibir nuevas tareas.
pause. El nodo deja de recibir nuevas tareas de manera indefinida, pero no desecha las que ya tiene corriendo.
drain. Le indica a Swarm que vacíe todas las tareas del nodo y lo mantenga así de manera indefinida. Si un servicio requiere un número definido de réplicas, Swarm redistribuye la respectiva carga del nodo drenado a otro nodo disponible.

Ver más en Administrar nodos de Swarm.

Entendido

docker node ls
docker  node inspect --pretty swarmwork02
docker node update --availability drain swarmwork02
docker node update --availability active swarmwork02
docker service update -d --env-add UNA_VARIABLE=de-entorno --update-parallelism=0 app
docker service rm app

![](

como para hacer un cluster con raspberry 🤭

-- Como hacemos decirle que esto de aqui sacamelo

docker node ls
docker node inspect --pretty worker2

-- Le pasamos las replicas a los otros workers, es decir le quitamos replicas nuestro worker2

docker node update --availability drain worker2

-- Vamos a nuestro worker1 y observamos que tiene mucha carga

-- Vamos a nuestro manager, verificamos que nuetro worker2 esta en modo DRAIN y lo cambiamos a ACTIVE (observamos que no redistribuye las replicas a worker2)

docker node ls
docker node update --availability active worker2

-- Con este metodo podemos redistribuir, enviando las tareas a otros workers

docker service update -d --env-add UNA_VARIABLE=de-entorno --update-parallelism=0 app
docker service ps app

Porque no se debería aplicar lo de parallelism en un entorno productivo?

Producirías downtime de tu aplicación

Gracias por la respuesta jonatan-lazo, probablemente no formulé bien mi pregunta, debido a que en el video Guido ya da de respuesta lo del dowtime, pero mi duda esta mas ligada a que se debe que el parallelismo crea el downtime, porque lo produce.

en este video hay un fallo y es que cuando pasamos un node a drain y queremos actualizar el servicio para balancear la carga debemos debemos pasar nuetro worker2 a active o si no cuando hagamos update queda todo en el worker 1

# inspect node
docker node ls
docker node inspect --pretty wrkr2

# mode drain (clean load) and mode availability
docker node update --availability drain wrkr2
docker node update --availability active wrkr2

# Force redistribution 
docker service update -d --env-add UNA_VARIABLE=de-entorno --update-parallelism=0 app
docker service ps app

me surgio una duda con el ejemplo que dio, en caso de que detectaramos que un nodo tiene problemas de conectividad, supongo que poderia ser de acceso a internet, entonces como podriamos hacer para mandar instrucciones a travez del nodo a docker swarm si justamente esta teniendo problemsa de conexion, es decir, si en la maquina donde esta corriendo ese nodo se corta internet entonces los comandos que ponga no le van a llegar al swarm, ya que justamente no tiene acceso a internet

Este ejemplo hace referencia a entornos productivos como podria ser que tenes un servicio desplegado en varias provincias de un mismo pais y hay un terremoto en provincia A digamos y redistribuis la carga a la provincia B

lo que pasa la informacion esta en el manager de hecho justamente los comando

docker node ls
docker node inspect <node>
docker node update --availability drain <node>

se corren en el manager y no en el node, el estado de swarm lo manejan los managers

Si no quieren agregar una variable de entorno nueva para redistribuir el servicio a los workers cada vez que activan uno node worker pueden usar nada mas:

docker service update app --force

en lugar de:

docker service update -d --env-add VAR=value app

docker node update --availability drain workder2
docker node update --availability active workder2
# Actualizar alguna variable de entorno para forzar la redistribución de contenedores
docker service update -d --env-add UNA_VARIABLE=de-entorno app

Eliminar containers

asi es, mas especificamente, los containers en los nodos de el servicio que queires eliminar

docker node ls docker node inspect --pretty swarmwork02 docker node update --availability drain swarmwork02 docker node update --availability active swarmwork02 docker service update -d --env-add UNA_VARIABLE=de-entorno --update-parallelism=0 app docker service ps app docker service rm app

Genial :) yo me di el trabajo de hacerlo en un entorno local

Conceptos básicos

Docker Swarm sin gastar dinero en la nube

Escalando Docker con Docker Swarm

Por qué Docker Swarm es esencial para producción

Arquitectura de Docker Swarm: managers y workers

Los 12 factores para aplicaciones en Docker Swarm

Primeros pasos

Instalación de Docker en Mac, Ubuntu y Windows

Cómo iniciar Docker Swarm en tu máquina

Creando servicios en Docker Swarm

Cómo funciona docker service ps internamente

Qué es Play with Docker para practicar

Creando un Docker Swarm multinodo real

Administrando Servicios

Docker Swarm: escalado y rolling updates

Gestión de actualizaciones y fallos en Docker Swarm

Cómo exponer servicios Docker Swarm

Swarm avanzado

Cómo Docker Swarm enruta tráfico sin perder peticiones

Docker Swarm constraints: dónde correr cada tarea

Cómo drenar nodos en Docker Swarm sin downtime

Redes Overlay en Docker Swarm: Comunicación entre Servicios

Docker Stack: automatiza despliegues multinodo

Implementación de Reverse Proxy con Traefik en Docker Swarm

Swarm productivo

Implementación de Docker Swarm en Producción: Arquitectura y Gestión

Administración de Swarm con Portainer: Gestión y Despliegue

Optimización de Swarm: Mantenimiento, Logs y Monitoreo Avanzado

Conclusiones

Escalabilidad con Docker Swarm: listo para millones

Cómo drenar nodos en Docker Swarm sin downtime

Progreso del curso

Conceptos básicos

Primeros pasos

Administrando Servicios

Swarm avanzado

Swarm productivo

Conclusiones

Recursos

Recursos