Administrar y mantener un enjambre de motores Docker

Cuando ejecuta un enjambre de motores Docker, nodos de administrador son los componentes clave para gestionar el enjambre y almacenar el estado del enjambre. Es importante comprender algunas características clave de los nodos de administrador para implementar y mantener correctamente el enjambre.

Consulte Cómo funcionan los nodos para obtener una breve descripción general del modo Docker Swarm y la diferencia entre los nodos de administrador y de trabajador.

Operar nodos de administrador en un enjambre

Los nodos del administrador de enjambres utilizan el algoritmo de consenso de la balsa para administrar el estado del enjambre. Solo necesita comprender algunos conceptos generales de Raft para administrar un enjambre.

No hay límite en el número de nodos de administrador. La decisión sobre cuántos nodos de administrador implementar es un compromiso entre rendimiento y tolerancia a fallas. Agregar nodos de administrador a un enjambre hace que el enjambre sea más tolerante a fallas. Sin embargo, los nodos de administrador adicionales reducen el rendimiento de escritura porque más nodos deben reconocer las propuestas para actualizar el estado del enjambre. Esto significa más tráfico de ida y vuelta en la red.

Raft requiere que la mayoría de los gerentes, también llamados quórum, acuerden las actualizaciones propuestas para el enjambre, como adiciones o eliminaciones de nodos. Las operaciones de pertenencia están sujetas a las mismas restricciones que la replicación de estado.

Mantener el quórum de gerentes

Si el enjambre pierde el quórum de administradores, el enjambre no puede realizar tareas administrativas. Si su enjambre tiene varios administradores, siempre tenga más de dos. Para mantener el quórum, la mayoría de los gerentes debe estar disponible. Se recomienda un número impar de gerentes, porque el siguiente número par no hace que el quórum sea más fácil de mantener. Por ejemplo, ya sea que tenga 3 o 4 gerentes, aún puede perder solo 1 gerente y mantener el quórum. Si tiene 5 o 6 gerentes, aún puede perder solo dos.

Incluso si un enjambre pierde el quórum de gerentes, las tareas del enjambre en los nodos trabajadores existentes continúan ejecutándose. Sin embargo, los nodos de enjambre no se pueden agregar, actualizar ni eliminar, y las tareas nuevas o existentes no se pueden iniciar, detener, mover ni actualizar.

Consulte Recuperación de la pérdida del quórum para conocer los pasos de solución de problemas si pierde el quórum de administradores.

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

Al iniciar un enjambre, debe especificar el --advertise-addr bandera para anunciar su dirección a otros nodos de administrador en el enjambre. Para obtener más información, consulte Ejecutar el motor de Docker en modo enjambre. Debido a que los nodos de administrador están destinados a ser un componente estable de la infraestructura, debe usar un dirección IP fija para que la dirección de publicidad evite que el enjambre se vuelva inestable al reiniciar la máquina.

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

Las direcciones IP dinámicas están bien para los nodos trabajadores.

Agregar nodos de administrador para tolerancia a fallas

Debe mantener un número impar de administradores en el enjambre para respaldar las fallas de los nodos de administradores. Tener un número impar de administradores asegura que durante una partición de red, hay una mayor probabilidad de que el quórum permanezca disponible para procesar solicitudes si la red está dividida en dos conjuntos. No se garantiza mantener el quórum si encuentra más de dos particiones de red.

Por ejemplo, en un enjambre con 5 nodos, Si tu pierdes 3 nodos, no tienes quórum. Por lo tanto, no puede agregar o eliminar nodos hasta que recupere uno de los nodos de administrador no disponibles o recupere el enjambre con comandos de recuperación de desastres. Consulte Recuperarse de un desastre.

Si bien es posible reducir un enjambre a un solo nodo de administrador, es imposible degradar el último nodo de administrador. Esto asegura que usted mantenga el acceso al enjambre y que el enjambre aún pueda procesar solicitudes. Reducir la escala a un solo administrador es una operación insegura y no se recomienda. Si el último nodo abandona el enjambre inesperadamente durante la operación de degradación, el enjambre no estará disponible hasta que reinicie el nodo o reinicie con --force-new-cluster.

Gestiona la membresía del enjambre con el docker swarm y docker node subsistemas. Consulte Agregar nodos a un enjambre para obtener más información sobre cómo agregar nodos trabajadores y promover un nodo trabajador para que sea administrador.

Distribuir los nodos del administrador

Además de mantener un número impar de nodos de administrador, preste atención a la topología del centro de datos al colocar administradores. Para una tolerancia a fallas óptima, distribuya los nodos de administrador en un mínimo de 3 zonas de disponibilidad para admitir fallas de un conjunto completo de máquinas o escenarios de mantenimiento comunes. Si sufre una falla en cualquiera de esas zonas, el enjambre debe mantener el quórum de nodos de administrador disponibles para procesar solicitudes y reequilibrar las cargas de trabajo.

Ejecutar nodos exclusivos para el administrador

Por defecto, los nodos de administrador también actúan como nodos de trabajo. Esto significa que el programador puede asignar tareas a un nodo administrador. Para enjambres pequeños y no críticos, la asignación de tareas a los gerentes es de riesgo relativamente bajo siempre que programe los servicios utilizando limitaciones de recursos por UPC y memoria.

Sin embargo, debido a que los nodos administradores usan el algoritmo de consenso de Raft para replicar datos de manera consistente, son sensibles a la escasez de recursos. Debe aislar a los gerentes de su enjambre de los procesos que podrían bloquear las operaciones del enjambre, como los latidos del enjambre o las elecciones de líderes.

Para evitar interferencias con la operación del nodo administrador, puede drenar los nodos del administrador para que no estén disponibles como nodos trabajadores:

docker node update --availability drain <NODE>

Cuando drena un nodo, el programador reasigna las tareas que se ejecutan en el nodo a otros nodos trabajadores disponibles en el enjambre. También evita que el programador asigne tareas al nodo.

Agregar nodos de trabajo para el equilibrio de carga

Agregue nodos al enjambre para equilibrar la carga de su enjambre. Las tareas de servicio replicadas se distribuyen entre el enjambre de la manera más uniforme posible a lo largo del tiempo, siempre que los nodos de trabajo 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 una cantidad específica de CPU o cantidad de memoria, recuerde que los nodos trabajadores que no cumplen con estos requisitos no pueden ejecutar estas tareas.

Monitorear la salud del enjambre

Puede monitorear el estado de los nodos de administrador consultando la ventana acoplable nodes API en formato JSON a través de la /nodes Punto final HTTP. Referirse a documentación de la API de nodos para más información.

Desde la línea de comando, 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 trabajador que acepta tareas:

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

De esos comandos, podemos ver que manager1 está en el estado reachable como gerente y ready como trabajador.

Un unreachable El estado de salud significa que este nodo de administrador en particular es inaccesible desde otros nodos de administrador. En este caso, debe tomar medidas para restaurar el administrador inalcanzable:

• Reinicie el demonio y vea si el administrador vuelve como accesible.
• Reinicie la máquina.
• Si ni reiniciar ni reiniciar funciona, debe agregar otro nodo de administrador o promover un trabajador para que sea un nodo de administrador. También debe eliminar limpiamente la entrada de nodo fallida del administrador configurado con docker node demote <NODE> y docker node rm <id-node>.

Alternativamente, también puede obtener una descripción general de la salud del enjambre 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 debe reiniciar un nodo de administrador copiando el raft directorio de otro nodo. El directorio de datos es exclusivo para un ID de nodo. Un nodo solo puede usar una ID de nodo una vez para unirse al enjambre. El espacio de ID de nodo debe ser único a nivel mundial.

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

1. Para degradar el nodo a trabajador, ejecute docker node demote <NODE>.
2. Para eliminar el nodo del enjambre, ejecute docker node rm <NODE>.
3. Vuelva a unir el nodo al enjambre con un estado nuevo usando docker swarm join.

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

Eliminar un nodo a la fuerza

En la mayoría de los casos, debe cerrar un nodo antes de eliminarlo de un enjambre con el docker node rm mando. Si un nodo se vuelve inalcanzable, no responde o se ve comprometido, puede quitar el nodo a la fuerza sin apagarlo pasando el --force bandera. 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 eliminar por la fuerza un nodo de administrador, primero debe degradarlo al rol de trabajador. Asegúrese de tener siempre un número impar de nodos de administrador si degrada o elimina un administrador.

Retrocede el enjambre

Los nodos del administrador de Docker almacenan el estado del enjambre y los registros del administrador en el /var/lib/docker/swarm/ directorio. En 1.13 y versiones posteriores, estos datos incluyen las claves utilizadas para cifrar los registros de Raft. Sin estas llaves, no puedes restaurar el enjambre.

Puede hacer una copia de seguridad del enjambre con cualquier administrador. Utilice el siguiente procedimiento.

1. Si el enjambre tiene el bloqueo automático habilitado, necesita la llave de desbloqueo para restaurar el enjambre desde la copia de seguridad. Recupere la clave de desbloqueo si es necesario y guárdela en un lugar seguro. Si no está seguro, lea Bloquear su enjambre para proteger su clave de cifrado.

2. Detenga Docker en el administrador antes de realizar una copia de seguridad de los datos, de modo que no se modifiquen datos durante la copia de seguridad. Es posible realizar una copia de seguridad mientras el administrador se está ejecutando (una copia de seguridad “en caliente”), pero esto no se recomienda y sus resultados son menos predecibles al restaurar. Mientras el administrador está inactivo, otros nodos continúan generando datos de enjambre que no forman parte de esta copia de seguridad.

   Nota: Asegúrese de mantener el quórum de administradores de enjambres. Durante el tiempo que un administrador está cerrado, su enjambre es más vulnerable a perder el quórum si se pierden más nodos. La cantidad de gerentes que dirige es una compensación. Si regularmente elimina administradores para hacer copias de seguridad, considere ejecutar un enjambre de 5 administradores, de modo que pueda perder un administrador adicional mientras se ejecuta la copia de seguridad, sin interrumpir sus servicios.

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

4. Reinicie el administrador.

Para restaurar, consulte 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 enjambre como se describe en Copia de seguridad del enjambre, utilice el siguiente procedimiento para restaurar los datos a un nuevo enjambre.

1. Apague Docker en la máquina host de destino para el enjambre restaurado.

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

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

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

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

4. Inicie Docker en el nuevo nodo. Desbloquea el enjambre si es necesario. Reinicialice el enjambre usando el siguiente comando, de modo que este nodo no intente conectarse a nodos que eran parte del antiguo enjambre y que presumiblemente ya no existen.

   $ docker swarm init --force-new-cluster
   

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

6. Si usa el bloqueo automático, gire la llave de desbloqueo.

7. Agregue nodos de administrador y trabajador para que su nuevo enjambre alcance la capacidad operativa.

8. Restablezca su régimen de respaldo anterior en el nuevo enjambre.

Recuperarse de perder el quórum

Swarm es resistente a fallas y el enjambre puede recuperarse de cualquier número de fallas temporales del nodo (reinicios de la máquina o fallas con reinicio) u otros errores transitorios. Sin embargo, un enjambre no puede recuperarse automáticamente si pierde quórum. Las tareas en los nodos trabajadores existentes continúan ejecutándose, pero las tareas administrativas no son posibles, incluido el escalado o actualización de servicios y la unión o eliminación de nodos del enjambre. La mejor manera de recuperarse es volver a poner en línea los nodos de administrador que faltan. Si eso no es posible, continúe leyendo para conocer algunas opciones para recuperar su enjambre.

En un enjambre de N gerentes, siempre debe estar disponible un quórum (la mayoría) de nodos gerentes. Por ejemplo, en un enjambre con 5 gerentes, un mínimo de 3 deben estar operativos y en comunicación entre sí. En otras palabras, el enjambre puede tolerar hasta (N-1)/2 fallas permanentes más allá de las cuales no se pueden procesar las solicitudes que involucran la gestión de enjambres. Estos tipos de fallas incluyen la corrupción de datos o fallas de hardware.

Si pierde el quórum de administradores, no puede administrar el enjambre. Si ha perdido el quórum e intenta realizar cualquier operación de gestión en el enjambre, se produce 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 poner en línea los nodos fallidos. Si no puede hacer eso, la única forma de recuperarse de este estado es usar el --force-new-cluster acción desde un nodo administrador. Esto elimina a todos los administradores excepto al administrador desde el que se ejecutó el comando. El quórum se logra porque ahora solo hay un gerente. Ascienda a los nodos para que sean administradores hasta que tenga la cantidad deseada de administradores.

# From the node to recover
docker swarm init --force-new-cluster --advertise-addr node01:2377

Cuando ejecuta el docker swarm init comando con el --force-new-cluster , el motor de Docker donde ejecuta el comando se convierte en el nodo administrador de un enjambre de un solo nodo que es capaz de administrar y ejecutar servicios. El administrador tiene toda la información previa sobre los servicios y las tareas, los nodos de trabajo aún son parte del enjambre y los servicios aún se están ejecutando. Debe agregar o volver a agregar nodos de administrador para lograr la distribución de tareas anterior y asegurarse de tener suficientes administradores para mantener una alta disponibilidad y evitar perder el quórum.

Obligar al enjambre a reequilibrarse

Generalmente, no es necesario forzar al enjambre a reequilibrar sus tareas. Cuando agrega un nuevo nodo a un enjambre, o un nodo se vuelve a conectar al enjambre después de un período de indisponibilidad, el enjambre no da automáticamente una carga de trabajo al nodo inactivo. Esta es una decisión de diseño. Si el enjambre cambiaba periódicamente las tareas a diferentes nodos para mantener el equilibrio, los clientes que utilizan esas tareas se verían interrumpidos. El objetivo es evitar interrumpir los servicios en ejecución en aras del equilibrio entre el enjambre. 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 el equilibrio final, con una interrupción mínima para el usuario final.

En Docker 1.13 y versiones posteriores, puede usar el --force o -f bandera con el docker service update comando para obligar al servicio a redistribuir sus tareas entre los nodos trabajadores disponibles. Esto hace que se reinicien las tareas de servicio. Las aplicaciones del cliente pueden verse interrumpidas. Si lo ha configurado, su servicio utiliza una actualización continua.

Si usa una versión anterior y desea lograr un equilibrio uniforme de carga entre los trabajadores y no le importa interrumpir las tareas en ejecución, puede obligar a su enjambre a reequilibrarse al escalar temporalmente el servicio hacia arriba. Usar docker service inspect --pretty <servicename> para ver la escala configurada de un servicio. Cuando usas docker service scale, los nodos con el menor número de tareas están destinados a recibir las nuevas cargas de trabajo. Puede haber varios nodos con poca carga en su enjambre. Es posible que deba escalar el servicio en incrementos modestos varias veces para lograr el equilibrio que desea en todos los nodos.

Cuando la carga esté equilibrada a su satisfacción, puede reducir el servicio a la escala original. Puedes usar docker service ps para evaluar el saldo actual de su servicio en todos los nodos.

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

estibador, envase, enjambre, gerente, balsa