Cómo drenar nodos en Docker Swarm sin downtime

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?