Docker Swarm sobre VPN: les tasques s'executen, les crides entre serveis fallen

Tres gestors i cinc treballadors en dos llocs, units per un túnel, i docker service ls mostra tasques en marxa a banda i banda mentre les crides entre serveis expiren. Res dels registres del Swarm no sembla incorrecte. Aquesta combinació és la signatura d'un problema al pla de dades: el pla de control va trobar els nodes i les trames encapsulades no van fer mai el viatge.

La malla ha d'existir abans que ho faci l'overlay

L'overlay del Swarm empeny les trames encapsulades directament entre adreces de node, cosa que vol dir que cada node necessita una adreça que tots els altres nodes puguin assolir sense traducció, a la interfície que proporciona el túnel. Un túnel que només porta clients cap a un port publicat no n'hi ha prou. La capa inferior ha d'encaminar de node a node en tots dos sentits.

Proveu-ho abans de tocar el Swarm. Des de cada node, comproveu la ruta cap a l'adreça de túnel d'un company, feu-hi ping i després proveu el port de control. Si el ping funciona i el port no, el túnel està bé i hi ha un filtre pel mig.

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 interfície física en lloc de tun0 o wg0, l'overlay encapsularà cap a una adreça que el lloc remot no pot assolir, i el símptoma semblarà pèrdua de paquets.

Comproveu quina adreça anuncia cada node

El dimoni anuncia una adreça i els companys la fan servir per al pla de dades. En un amfitrió amb diverses xarxes és fàcil anunciar l'adreça LAN o pública mentre el túnel en porta una altra. Inspeccioneu-la en lloc de suposar-la, i fixeu-la en unir-vos amb --advertise-addr quan la predeterminada és incorrecta. Un node que anuncia una adreça que només ell pot assolir igualment s'uneix a l'eixam, i la fallada apareix més tard com a serveis que no poden parlar entre llocs.

Canviar l'adreça anunciada més tard no és una edició de configuració, perquè el node ha de sortir i tornar-se a unir.

Anoteu l'adreça anunciada per node a les vostres notes, perquè explica la majoria de fallades asimètriques.

El masquerade és el culpable habitual

Quan una passarel·la se situa entre els nodes i el túnel, l'error habitual és fer masquerade de tot el que surt de la interfície física. Això reescriu també les adreces internes de l'overlay, de manera que cada company sembla venir de la passarel·la i els companys VXLAN deixen de reconèixer-se. El resultat és trànsit encapsulat absent o unidireccional mentre els pings normals encara funcionen.

Encamineu el prefix de l'overlay per la passarel·la i deixeu-lo sense traduir. Si la traducció és realment necessària per a un altre prefix, limiteu-la allà i mai al rang que fa servir l'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

Comproveu l'ordre de les regles i també el text, perquè un MASQUERADE ampli abans a la cadena guanya sobre una excepció estreta després.

VXLAN necessita espai al paquet

VXLAN afegeix 50 bytes a les trames que transporta. Una capa inferior de 1500 bytes que transporta una trama interna de 1500 bytes produeix un paquet encapsulat que cap camí no lliurarà, i la fallada sembla un descobriment de serveis intermitent més que un problema de mida. O baixeu l'MTU del túnel als dos extrems o configureu l'MTU de l'overlay perquè el controlador anunciï una càrrega útil que hi càpiga.

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

La xarxa ingress es crea automàticament, així que canviar-la vol dir eliminar-la i tornar-la a crear en lloc d'editar-la in situ.

Si només arregleu un costat del túnel, l'MTU més petit continua sent el que importa.

Vigileu el pla de dades, no els registres

Captureu el port VXLAN als dos extrems. Les trames que surten d'un costat i arriben a l'altre volen dir que la capa inferior està bé i que el problema és dins de l'overlay. Les trames que surten i no arriben mai volen dir una ruta o un filtre. Les trames que no surten gens volen dir que l'adreça d'origen és incorrecta.

Les fallades de descobriment de serveis que s'esvaeixen al cap d'uns segons solen apuntar a la quota de paquets o a un camí inestable, no al quòrum de raft.

Guardeu la captura d'una finestra de funcionament, perquè comparar-la amb la trencada és més ràpid que rellegir la configuració.