Administrar y mantener un swarm de Docker Engines

Cuando ejecutas un swarm de Docker Engines, los nodos administradores (managers) son los componentes clave para gestionar el swarm y almacenar su estado. Es importante comprender algunas características clave de los nodos administradores para desplegar y mantener el swarm correctamente.

Consulta Cómo funcionan los nodos para obtener una breve descripción general del modo Docker Swarm y la diferencia entre los nodos administradores y trabajadores.

Operar nodos administradores en un swarm

Los nodos administradores de Swarm utilizan el Algoritmo de Consenso Raft para gestionar el estado del swarm. Solo necesitas comprender algunos conceptos generales de Raft para gestionar un swarm.

No hay límite en el número de nodos administradores. La decisión sobre cuántos nodos administradores implementar es un compromiso entre rendimiento y tolerancia a fallos. Añadir nodos administradores a un swarm lo hace más tolerante a fallos. Sin embargo, los nodos administradores adicionales reducen el rendimiento de escritura porque más nodos deben confirmar las propuestas para actualizar el estado del swarm. Esto significa un mayor tráfico de ida y vuelta en la red.

Raft requiere que la mayoría de los administradores, también conocida como quórum, esté de acuerdo con las actualizaciones propuestas para el swarm, como la adición o eliminación de nodos. Las operaciones de membresía están sujetas a las mismas restricciones que la replicación del estado.

Mantener el quórum de los administradores

Si el swarm pierde el quórum de los administradores, no podrá realizar tareas de gestión. Si tu swarm tiene múltiples administradores, ten siempre más de dos. Para mantener el quórum, la mayoría de los administradores debe estar disponible. Se recomienda un número impar de administradores, ya que el siguiente número par no facilita el mantenimiento del quórum. Por ejemplo, ya sea que tengas 3 o 4 administradores, solo puedes perder 1 de ellos para mantener el quórum. Si tienes 5 o 6 administradores, solo puedes perder dos.

Incluso si un swarm pierde el quórum de administradores, las tareas del swarm en los nodos trabajadores existentes continuarán ejecutándose. Sin embargo, no se podrán añadir, actualizar ni eliminar nodos del swarm, y tampoco se podrán iniciar, detener, mover ni actualizar tareas nuevas o existentes.

Consulta Recuperarse de la pérdida del quórum para conocer los pasos de resolución de problemas si pierdes el quórum de administradores.

Configurar el administrador para anunciarse en una dirección IP estática

Al inicializar un swarm, debes especificar la opción --advertise-addr para anunciar tu dirección a otros nodos administradores del swarm. Para más información, consulta Ejecutar Docker Engine en modo Swarm. Dado que los nodos administradores están destinados a ser un componente estable de la infraestructura, debes utilizar una dirección IP fija como dirección de anuncio para evitar que el swarm se vuelva inestable al reiniciar la máquina.

Si todo el swarm se reinicia y posteriormente cada nodo administrador obtiene una nueva dirección IP, no habrá forma de que ningún nodo se comunique con un administrador existente. Por lo tanto, el swarm quedará suspendido mientras los nodos intentan comunicarse entre sí en sus direcciones IP anteriores.

Las direcciones IP dinámicas son válidas para los nodos trabajadores.

Añadir nodos administradores para tolerancia a fallos

Debes mantener un número impar de administradores en el swarm para soportar fallos de nodos administradores. Tener un número impar garantiza que, durante una partición de red, exista una mayor probabilidad de que el quórum siga estando disponible para procesar solicitudes si la red se divide en dos conjuntos. Mantener el quórum no está garantizado si experimentas más de dos particiones de red.

Por ejemplo, en un swarm con 5 nodos, si pierdes 3 nodos, no tendrás quórum. Por lo tanto, no podrás añadir ni eliminar nodos hasta que recuperes uno de los nodos administradores no disponibles o recuperes el swarm con comandos de recuperación ante desastres. Consulta Recuperarse de un desastre.

Aunque es posible reducir un swarm a un solo nodo administrador, es imposible degradar al último nodo administrador. Esto garantiza que mantengas el acceso al swarm y que este pueda seguir procesando solicitudes. Reducir a un solo administrador es una operación insegura y no se recomienda. Si el último nodo abandona el swarm de forma inesperada durante la operación de degradación, el swarm dejará de estar disponible hasta que reinicies el nodo o reinicies con --force-new-cluster.

Gestionas la pertenencia al swarm con los subsistemas docker swarm y docker node. Consulta Añadir nodos a un swarm para obtener más información sobre cómo añadir nodos trabajadores y promover un nodo trabajador a administrador.

Distribuir los nodos administradores

Además de mantener un número impar de nodos administradores, presta atención a la topología del centro de datos al ubicar los administradores. Para una tolerancia a fallos óptima, distribuye los nodos administradores en un mínimo de 3 zonas de disponibilidad para soportar fallos de un conjunto completo de máquinas o escenarios de mantenimiento comunes. Si sufres un fallo en cualquiera de esas zonas, el swarm debería mantener el quórum de nodos administradores disponibles para procesar solicitudes y rebalancear las cargas de trabajo.

Ejecutar nodos exclusivos para administración

Por defecto, los nodos administradores también actúan como nodos trabajadores. Esto significa que el planificador puede asignar tareas a un nodo administrador. Para swarms pequeños y no críticos, asignar tareas a los administradores es de riesgo relativamente bajo, siempre que programes los servicios utilizando restricciones de recursos de CPU y memoria.

Sin embargo, debido a que los nodos administradores utilizan el algoritmo de consenso Raft para replicar datos de manera consistente, son sensibles a la falta de recursos. Debes aislar los administradores de tu swarm de los procesos que puedan bloquear las operaciones del swarm, como los latidos (heartbeats) del swarm o las elecciones de líder.

Para evitar interferencias con el funcionamiento de los nodos administradores, puedes drenar (drain) los nodos administradores para que no estén disponibles como nodos trabajadores:

$ docker node update --availability drain <NODE>

Cuando drenas un nodo, el planificador reasigna cualquier tarea que se esté ejecutando en él a otros nodos trabajadores disponibles en el swarm. También evita que el planificador asigne nuevas tareas al nodo.

Añadir nodos trabajadores para el balanceo de carga

Añade nodos al swarm para balancear la carga del swarm. Las tareas del servicio replicado se distribuyen por el swarm de la forma más uniforme posible a lo largo del tiempo, siempre que los nodos trabajadores coincidan con los requisitos de los servicios. Al limitar un servicio para que se ejecute solo en tipos específicos de nodos, como nodos con un número específico de CPU o cantidad de memoria, recuerda que los nodos trabajadores que no cumplan con estos requisitos no podrán ejecutar estas tareas.

Supervisar la salud del swarm

Puedes supervisar la salud de los nodos administradores consultando la API de nodes de Docker en formato JSON a través del endpoint HTTP /nodes. Consulta la documentación de la API de nodos para obtener más información.

Desde la línea de comandos, ejecuta docker node inspect <id-node> para consultar los nodos. Por ejemplo, para consultar la accesibilidad del nodo como administrador:

$ docker node inspect manager1 --format "{{ .ManagerStatus.Reachability }}"
reachable

Para consultar el estado del nodo como un trabajador que acepta tareas:

$ docker node inspect manager1 --format "{{ .Status.State }}"
ready

A partir de esos comandos, se puede ver que manager1 tiene tanto el estado reachable (accesible) como administrador como ready (listo) como trabajador.

Un estado de salud unreachable (inaccesible) significa que este nodo administrador en particular es inaccesible desde otros nodos administradores. En este caso, debes tomar medidas para restaurar el administrador inaccesible:

• Reinicia el demonio y observa si el administrador vuelve a estar accesible.
• Reinicia la máquina.
• Si ni reiniciar ni apagar y encender funcionan, debes añadir otro nodo administrador o promover un trabajador a nodo administrador. También debes eliminar limpiamente la entrada del nodo fallido del conjunto de administradores con docker node demote <NODE> y docker node rm <id-node>.

Alternativamente, también puedes obtener una descripción general de la salud del swarm desde un nodo administrador con docker node ls:

$ docker node ls
ID                           HOSTNAME  MEMBERSHIP  STATUS  AVAILABILITY  MANAGER STATUS
1mhtdwhvsgr3c26xxbnzdc3yp    node05    Accepted    Ready   Active
516pacagkqp2xc3fk9t1dhjor    node02    Accepted    Ready   Active        Reachable
9ifojw8of78kkusuc4a6c23fx *  node01    Accepted    Ready   Active        Leader
ax11wdpwrrb6db3mfjydscgk7    node04    Accepted    Ready   Active
bb1nrq2cswhtbg4mrsqnlx1ck    node03    Accepted    Ready   Active        Reachable
di9wxgz8dtuh9d2hn089ecqkf    node06    Accepted    Ready   Active

Solucionar problemas de un nodo administrador

Nunca debes reiniciar un nodo administrador copiando el directorio raft de otro nodo. El directorio de datos es único para cada ID de nodo. Un nodo solo puede usar un ID de nodo una vez para unirse al swarm. El espacio de ID de nodo debe ser globalmente único.

Para volver a unir limpiamente un nodo administrador a un clúster:

1. Degrada el nodo a trabajador usando docker node demote <NODE>.
2. Elimina el nodo del swarm usando docker node rm <NODE>.
3. Vuelve a unir el nodo al swarm con un estado limpio usando docker swarm join.

Para obtener más información sobre cómo unir un nodo administrador a un swarm, consulta Unir nodos a un swarm.

Forzar la eliminación de un nodo

En la mayoría de los casos, debes apagar un nodo antes de eliminarlo de un swarm con el comando docker node rm. Si un nodo se vuelve inaccesible, no responde o se ve comprometido, puedes forzar su eliminación sin apagarlo pasando la opción --force. Por ejemplo, si node9 se ve comprometido:

$ docker node rm node9

Error response from daemon: rpc error: code = 9 desc = node node9 is not down and can't be removed

$ docker node rm --force node9

Node node9 removed from swarm

Antes de forzar la eliminación de un nodo administrador, primero debes degradarlo al rol de trabajador. Asegúrate de tener siempre un número impar de nodos administradores si degradas o eliminas un administrador.

Realizar una copia de seguridad del swarm

Los nodos administradores de Docker almacenan el estado del swarm y los registros del administrador en el directorio /var/lib/docker/swarm/. Estos datos incluyen las claves utilizadas para cifrar los registros de Raft. Sin estas claves, no podrás restaurar el swarm.

Puedes realizar una copia de seguridad del swarm utilizando cualquier administrador. Sigue este procedimiento:

1. Si el swarm tiene habilitado el bloqueo automático, necesitarás la clave de desbloqueo para restaurar el swarm desde la copia de seguridad. Obtén la clave de desbloqueo si es necesario y guárdala en un lugar seguro. Si no estás seguro, lee Bloquear el swarm para proteger su clave de cifrado.

2. Detén Docker en el administrador antes de realizar la copia de seguridad de los datos, de modo que no se modifique ningún dato durante el proceso. Es posible realizar una copia de seguridad mientras el administrador está en ejecución (una copia de seguridad en caliente o "hot backup"), pero esto no es recomendable y los resultados son menos predecibles al restaurar. Mientras el administrador esté inactivo, otros nodos seguirán generando datos del swarm que no formarán parte de esta copia de seguridad.

   Note

   Asegúrate de mantener el quórum de los administradores del swarm. Durante el tiempo que un administrador esté apagado, el swarm es más vulnerable a perder el quórum si se pierden más nodos. La cantidad de administradores que ejecutas es un compromiso. Si apagas los administradores con regularidad para hacer copias de seguridad, considera ejecutar un swarm de cinco administradores, de modo que puedas perder un administrador adicional mientras se realiza la copia de seguridad, sin interrumpir tus servicios.

3. Realiza una copia de seguridad de todo el directorio /var/lib/docker/swarm.

4. Reinicia el administrador.

Para restaurar, consulta Restaurar desde una copia de seguridad.

Recuperarse de un desastre

Restaurar desde una copia de seguridad

Después de realizar una copia de seguridad del swarm como se describe en Realizar una copia de seguridad del swarm, sigue este procedimiento para restaurar los datos en un nuevo swarm.

1. Apaga Docker en la máquina host de destino para el swarm restaurado.

2. Elimina el contenido del directorio /var/lib/docker/swarm en el nuevo swarm.

3. Restaura el directorio /var/lib/docker/swarm con el contenido de la copia de seguridad.

   Note

   El nuevo nodo utiliza la misma clave de cifrado para el almacenamiento en disco que el anterior. No es posible cambiar las claves de cifrado del almacenamiento en disco en este momento.

   En el caso de un swarm con bloqueo automático habilitado, la clave de desbloqueo también es la misma que en el antiguo swarm, y se necesita la clave de desbloqueo para restaurar el swarm.

4. Inicia Docker en el nuevo nodo. Desbloquea el swarm si es necesario. Reinicializa el swarm utilizando el siguiente comando, para que este nodo no intente conectarse a los nodos que formaban parte del antiguo swarm y que presumiblemente ya no existen.

   $ docker swarm init --force-new-cluster
   

5. Verifica que el estado del swarm sea el esperado. Esto puede incluir pruebas específicas de la aplicación o verificar la salida de docker service ls para asegurarse de que todos los servicios esperados estén presentes.

6. Si utilizas el bloqueo automático, rota la clave de desbloqueo.

7. Añade nodos administradores y trabajadores para llevar tu nuevo swarm a su capacidad operativa.

8. Restablece tu régimen de copias de seguridad anterior en el nuevo swarm.

Recuperarse de la pérdida del quórum

Swarm es resistente a fallos y puede recuperarse de cualquier cantidad de fallos temporales de nodos (reinicios de máquinas o caídas con reinicio) u otros errores transitorios. Sin embargo, un swarm no puede recuperarse automáticamente si pierde el quórum. Las tareas en los nodos trabajadores existentes continúan ejecutándose, pero las tareas administrativas no son posibles, incluyendo la escala o actualización de servicios y la unión o eliminación de nodos del swarm. La mejor manera de recuperarse es volver a conectar los nodos administradores que faltan. Si eso no es posible, continúa leyendo para conocer algunas opciones para recuperar tu swarm.

En un swarm de N administradores, siempre debe estar disponible un quórum (una mayoría) de nodos administradores. Por ejemplo, en un swarm con cinco administradores, un mínimo de tres debe estar operativo y en comunicación entre sí. En otras palabras, el swarm puede tolerar hasta (N-1)/2 fallos permanentes, más allá de los cuales no se pueden procesar solicitudes relacionadas con la gestión del swarm. Estos tipos de fallos incluyen corrupción de datos o fallos de hardware.

Si pierdes el quórum de administradores, no podrás administrar el swarm. Si has perdido el quórum e intentas realizar cualquier operación de gestión en el swarm, se producirá un error:

Error response from daemon: rpc error: code = 4 desc = context deadline exceeded

La mejor manera de recuperarse de la pérdida del quórum es volver a conectar los nodos fallidos. Si no puedes hacer eso, la única forma de recuperarte de este estado es usar la acción --force-new-cluster desde un nodo administrador. Esto elimina a todos los administradores excepto al administrador desde el cual se ejecutó el comando. El quórum se alcanza porque ahora solo hay un administrador. Promueve nodos a administradores hasta que tengas el número deseado.

Desde el nodo a recuperar, ejecuta:

$ docker swarm init --force-new-cluster --advertise-addr node01:2377

Al ejecutar el comando docker swarm init con la opción --force-new-cluster, el Docker Engine donde ejecutas el comando se convierte en el nodo administrador de un swarm de un solo nodo capaz de gestionar y ejecutar servicios. El administrador tiene toda la información previa sobre servicios y tareas, los nodos trabajadores siguen formando parte del swarm y los servicios se siguen ejecutando. Debes añadir o volver a añadir nodos administradores para lograr la distribución de tareas anterior y asegurarte de tener suficientes administradores para mantener la alta disponibilidad y evitar perder el quórum.

Forzar al swarm a rebalancearse

Generalmente, no necesitas forzar al swarm a rebalancear sus tareas. Cuando añades un nuevo nodo a un swarm, o un nodo se vuelve a conectar tras un periodo de inactividad, el swarm no asigna automáticamente carga de trabajo al nodo inactivo. Esta es una decisión de diseño. Si el swarm desplazara periódicamente tareas a diferentes nodos en aras del equilibrio, los clientes que utilizan esas tareas se verían interrumpidos. El objetivo es evitar interrumpir los servicios en ejecución por el mero hecho de mantener el equilibrio en todo el swarm. Cuando se inician nuevas tareas, o cuando un nodo con tareas en ejecución deja de estar disponible, esas tareas se asignan a los nodos menos ocupados. El objetivo es un equilibrio final con la mínima interrupción para el usuario final.

Puedes utilizar la opción --force o -f con el comando docker service update para forzar al servicio a redistribuir sus tareas entre los nodos trabajadores disponibles. Esto provoca el reinicio de las tareas del servicio. Las aplicaciones cliente pueden verse afectadas. Si lo has configurado, tu servicio utilizará una actualización continua (rolling update).

Si utilizas una versión anterior y quieres lograr un equilibrio uniforme de la carga entre los trabajadores sin que te importe interrumpir las tareas en ejecución, puedes forzar el reequilibrio del swarm escalando temporalmente el servicio hacia arriba. Utiliza docker service inspect --pretty <servicename> para ver la escala configurada de un servicio. Cuando utilizas docker service scale, los nodos con menor número de tareas son los elegidos para recibir las nuevas cargas de trabajo. Puede haber múltiples nodos con baja carga en tu swarm. Es posible que debas escalar el servicio en pequeños incrementos unas cuantas veces para lograr el equilibrio que deseas en todos los nodos.

Cuando la carga esté balanceada a tu satisfacción, puedes volver a reducir el servicio a su escala original. Puedes utilizar docker service ps para evaluar el equilibrio actual de tu servicio entre los nodos.

Consulta también docker service scale y docker service ps.