Docker Swarm sur VPN : les tâches tournent, les appels entre services échouent

Trois gestionnaires et cinq workers sur deux sites, reliés par un tunnel, et docker service ls montre des tâches en cours des deux côtés tandis que les appels entre services expirent. Rien dans les journaux de Swarm ne semble anormal. Cette combinaison est la signature d'un problème de plan de données : le plan de contrôle a trouvé les nœuds, et les trames encapsulées n'ont jamais fait le trajet.

Le maillage doit exister avant l'overlay

L'overlay de Swarm pousse les trames encapsulées directement entre les adresses de nœuds, ce qui veut dire que chaque nœud a besoin d'une adresse que tous les autres peuvent joindre sans traduction, sur l'interface fournie par le tunnel. Un tunnel qui ne transporte que des clients vers un port publié ne suffit pas. Le sous-réseau sous-jacent doit router de nœud à nœud dans les deux sens.

Testez cela avant de toucher à Swarm. Depuis chaque nœud, vérifiez la route vers l'adresse de tunnel d'un pair, faites un ping, puis testez le port de contrôle. Si le ping fonctionne et pas le port, le tunnel est bon et un filtre est en travers.

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 route pointe vers l'interface physique au lieu de tun0 ou wg0, l'overlay encapsulera vers une adresse que le site distant ne peut pas joindre, et le symptôme ressemblera à une perte de paquets.

Vérifiez quelle adresse chaque nœud annonce

Le démon annonce une adresse, et les pairs l'utilisent pour le plan de données. Sur un hôte multi-réseaux, il est facile d'annoncer l'adresse LAN ou publique alors que le tunnel transporte autre chose. Inspectez-la au lieu de la supposer, et fixez-la au moment de rejoindre avec --advertise-addr quand la valeur par défaut est mauvaise. Un nœud qui annonce une adresse que lui seul peut joindre rejoint quand même le swarm, et la panne apparaît plus tard sous forme de services qui ne peuvent pas communiquer entre sites.

Changer l'adresse annoncée plus tard n'est pas une modification de configuration, car le nœud doit quitter puis rejoindre.

Notez l'adresse annoncée par nœud dans vos notes, car elle explique la plupart des pannes asymétriques.

Le masquerade est le coupable habituel

Quand une passerelle se trouve entre les nœuds et le tunnel, l'erreur courante est de masquerader tout ce qui sort de l'interface physique. Cela réécrit aussi les adresses internes de l'overlay, si bien que chaque pair semble venir de la passerelle et que les pairs VXLAN cessent de se reconnaître. Le résultat est un trafic encapsulé absent ou unidirectionnel alors que les pings simples fonctionnent encore.

Routez le préfixe de l'overlay via la passerelle et laissez-le non traduit. Si une traduction est vraiment nécessaire pour un autre préfixe, limitez-la à celui-ci et jamais à la plage utilisée par 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

Vérifiez l'ordre des règles autant que leur texte, car un MASQUERADE large plus tôt dans la chaîne l'emporte sur une exception étroite plus tard.

VXLAN a besoin de place dans le paquet

VXLAN ajoute 50 octets aux trames qu'il transporte. Un sous-réseau de 1500 octets transportant une trame interne de 1500 octets produit un paquet encapsulé qu'aucun chemin ne livrera, et la panne ressemble à une découverte de services intermittente plutôt qu'à un problème de taille. Baissez la MTU du tunnel aux deux extrémités ou réglez la MTU de l'overlay pour que le pilote annonce une charge utile qui passe.

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

Le réseau ingress est créé automatiquement, donc le changer signifie le supprimer et le recréer plutôt que l'éditer sur place.

Si vous ne corrigez qu'un côté du tunnel, la MTU la plus petite reste celle qui compte.

Surveillez le plan de données, pas les journaux

Capturez le port VXLAN aux deux extrémités. Des trames qui partent d'un côté et arrivent de l'autre signifient que le sous-réseau est bon et que le problème est dans l'overlay. Des trames qui partent et n'arrivent jamais signifient une route ou un filtre. Des trames qui ne partent pas du tout signifient que l'adresse source est mauvaise.

Les échecs de découverte de services qui disparaissent au bout de quelques secondes pointent généralement vers le budget de paquets ou un chemin instable, pas vers le quorum raft.

Conservez la capture d'une fenêtre qui fonctionne, car la comparer avec celle qui est cassée est plus rapide que relire la configuration.