Docker Swarm sobre VPN: as tarefas execútanse, as chamadas entre servizos fallan

Tres xestores e cinco traballadores en dous sitios, unidos por un túnel, e docker service ls amosa tarefas en execución nos dous lados mentres as chamadas entre servizos caducan. Nada nos rexistros de Swarm parece incorrecto. Esa combinación é a sinatura dun problema no plano de datos: o plano de control atopou os nodos e as tramas encapsuladas nunca fixeron a viaxe.

A malla ten que existir antes ca o overlay

O overlay de Swarm empuxa as tramas encapsuladas directamente entre enderezos de nodo, o que significa que cada nodo necesita un enderezo que todos os demais poidan acadar sen tradución, na interface que proporciona o túnel. Un túnel que só leva clientes a un porto publicado non abonda. A capa inferior ten que encamiñar de nodo a nodo nos dous sentidos.

Proba isto antes de tocar Swarm. Desde cada nodo, comproba a ruta cara ao enderezo de túnel dun par, fai ping e despois proba o porto de control. Se o ping funciona e o porto non, o túnel está ben e hai un filtro polo medio.

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

Se a ruta apunta á interface física en lugar de tun0 ou wg0, o overlay encapsulará cara a un enderezo que o sitio remoto non pode acadar, e o síntoma parecerá perda de paquetes.

Comproba que enderezo anuncia cada nodo

O daemon anuncia un enderezo e os pares úsano para o plano de datos. Nun host con varias redes é doado anunciar o enderezo LAN ou o público mentres o túnel transporta outra cousa. Inspecciona o en lugar de supoñelo, e fíxao ao unirte con --advertise-addr cando o predeterminado é incorrecto. Un nodo que anuncia un enderezo que só el acada únese igualmente ao swarm, e o fallo aparece máis tarde como servizos que non poden falar entre sitios.

Cambiar o enderezo anunciado máis tarde non é unha edición de configuración, porque o nodo ten que saír e volver unirse.

Anota o enderezo anunciado por nodo nas túas notas, porque explica a maioría dos fallos asimétricos.

O masquerade é o culpable habitual

Cando unha pasarela se sitúa entre os nodos e o túnel, o erro habitual é aplicar masquerade a todo o que sae da interface física. Iso reescribe tamén os enderezos internos do overlay, así que cada par parece vir da pasarela e os pares VXLAN deixan de recoñecerse. O resultado é tráfico encapsulado ausente ou unidireccional mentres os ping normais seguen funcionando.

Encamiña o prefixo do overlay pola pasarela e déixao sen traducir. Se a tradución é realmente necesaria para outro prefixo, limita a ese e nunca ao rango que usa o 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

Comproba a orde das regras ademais do texto, porque un MASQUERADE amplo antes na cadea gaña a unha excepción estreita despois.

VXLAN necesita espazo no paquete

VXLAN engade 50 bytes ás tramas que transporta. Unha capa inferior de 1500 bytes que transporta unha trama interna de 1500 bytes produce un paquete encapsulado que ningún camiño entregará, e o fallo parece un descubrimento de servizos intermitente máis ca un problema de tamaño. Ou baixa a MTU do túnel nos dous extremos ou configura a MTU do overlay para que o controlador anuncie unha carga útil que encaixe.

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

A rede ingress créase automaticamente, así que cambiala significa eliminarla e volver creala en lugar de editarla no lugar.

Se só arranxas un lado do túnel, a MTU máis pequena segue sendo a que importa.

Vixía o plano de datos, non os rexistros

Captura o porto VXLAN nos dous extremos. As tramas que saen dun lado e chegan ao outro significan que a capa inferior está ben e que o problema está dentro do overlay. As tramas que saen e nunca chegan significan unha ruta ou un filtro. As tramas que non saen de ningún xeito significan que o enderezo de orixe é incorrecto.

Os fallos de descubrimento de servizos que se despexan aos poucos segundos adoitan apuntar ao orzamento de paquetes ou a un camiño inestable, non ao quórum de raft.

Garda a captura dunha xanela que funciona, porque comparala coa rota é máis rápido ca reler a configuración.