Docker Swarm sobre VPN: las tareas se ejecutan, las llamadas entre servicios fallan

Tres gestores y cinco trabajadores en dos sitios, unidos por un túnel, y docker service ls muestra tareas en ejecución en ambos lados mientras las llamadas entre servicios caducan. Nada en los registros de Swarm parece incorrecto. Esa combinación es la firma de un problema en el plano de datos: el plano de control encontró los nodos y las tramas encapsuladas nunca hicieron el viaje.

La malla tiene que existir antes que el overlay

El overlay de Swarm empuja las tramas encapsuladas directamente entre direcciones de nodo, lo que significa que cada nodo necesita una dirección que todos los demás puedan alcanzar sin traducción, en la interfaz que proporciona el túnel. Un túnel que solo lleva clientes a un puerto publicado no basta. La capa inferior tiene que enrutar de nodo a nodo en ambos sentidos.

Pruébelo antes de tocar Swarm. Desde cada nodo, compruebe la ruta hacia la dirección de túnel de un par, hágale ping y luego pruebe el puerto de control. Si el ping funciona y el puerto no, el túnel está bien y hay un filtro en medio.

ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377

Si la ruta apunta a la interfaz física en lugar de tun0 o wg0, el overlay encapsulará hacia una dirección que el sitio remoto no puede alcanzar, y el síntoma parecerá pérdida de paquetes.

Compruebe qué dirección anuncia cada nodo

El demonio anuncia una dirección y los pares la usan para el plano de datos. En un host con varias redes es fácil anunciar la dirección LAN o la pública mientras el túnel transporta otra cosa. Inspecciónela en lugar de suponerla, y fíjela al unirse con --advertise-addr cuando la predeterminada sea incorrecta. Un nodo que anuncia una dirección que solo él alcanza se une igualmente al swarm, y el fallo aparece más tarde como servicios que no pueden hablar entre sitios.

Cambiar la dirección anunciada más tarde no es una edición de configuración, porque el nodo tiene que salir y volver a unirse.

Anote la dirección anunciada por nodo, porque explica la mayoría de los fallos asimétricos.

El masquerade es el culpable habitual

Cuando una puerta de enlace se sitúa entre los nodos y el túnel, el error común es aplicar masquerade a todo lo que sale de la interfaz física. Eso también reescribe las direcciones internas del overlay, así que cada par parece venir de la puerta de enlace y los pares VXLAN dejan de reconocerse. El resultado es tráfico encapsulado ausente o unidireccional mientras los ping normales siguen funcionando.

Enrute el prefijo del overlay por la puerta de enlace y déjelo sin traducir. Si la traducción es realmente necesaria para otro prefijo, limite a ese y nunca al rango que usa el overlay.

ip route add 172.16.0.0/22 via 10.20.0.1
iptables -t nat -I POSTROUTING -o tun0 -s 172.16.0.0/22 -j ACCEPT

Compruebe el orden de las reglas además del texto, porque un MASQUERADE amplio antes en la cadena gana a una excepción estrecha después.

VXLAN necesita espacio en el paquete

VXLAN añade 50 bytes a las tramas que transporta. Una capa inferior de 1500 bytes que transporta una trama interna de 1500 bytes produce un paquete encapsulado que ningún camino entregará, y el fallo parece un descubrimiento de servicios intermitente más que un problema de tamaño. O bien baje la MTU del túnel en ambos extremos o configure la MTU del overlay para que el controlador anuncie una carga útil que quepa.

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay

La red ingress se crea automáticamente, así que cambiarla significa eliminarla y volver a crearla en lugar de editarla en el sitio.

Si solo arregla un lado del túnel, la MTU más pequeña sigue siendo la que importa.

Vigile el plano de datos, no los registros

Capture el puerto VXLAN en ambos extremos. Las tramas que salen de un lado y llegan al otro significan que la capa inferior está bien y que el problema está dentro del overlay. Las tramas que salen y nunca llegan significan una ruta o un filtro. Las tramas que no salen en absoluto significan que la dirección de origen es incorrecta.

Los fallos de descubrimiento de servicios que se despejan a los pocos segundos suelen apuntar al presupuesto de paquetes o a un camino inestable, no al quórum de raft.

Guarde la captura de una ventana en funcionamiento, porque compararla con la rota es más rápido que releer la configuración.