Docker Swarm sobre VPN: as tarefas correm, as chamadas entre serviços falham

Três gestores e cinco trabalhadores em dois locais, ligados por um túnel, e o docker service ls mostra tarefas em execução nos dois lados enquanto as chamadas entre serviços expiram. Nada nos registos do Swarm parece errado. Essa combinação é a assinatura de um problema no plano de dados: o plano de controlo encontrou os nós, e as tramas encapsuladas nunca fizeram a viagem.

A malha tem de existir antes do overlay

O overlay do Swarm empurra as tramas encapsuladas diretamente entre endereços de nós, o que significa que cada nó precisa de um endereço que todos os outros alcancem sem tradução, na interface que o túnel fornece. Um túnel que só leva clientes a uma porta publicada não chega. A camada inferior tem de encaminhar de nó para nó nos dois sentidos.

Teste isso antes de tocar no Swarm. De cada nó, verifique a rota até ao endereço de túnel de um par, faça ping e depois teste a porta de controlo. Se o ping funciona e a porta não, o túnel está bem e há um filtro no caminho.

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 rota apontar para a interface física em vez de tun0 ou wg0, o overlay vai encapsular para um endereço que o local remoto não alcança, e o sintoma parecerá perda de pacotes.

Verifique que endereço cada nó anuncia

O daemon anuncia um endereço, e os pares usam-no para o plano de dados. Num anfitrião com várias redes é fácil anunciar o endereço LAN ou público enquanto o túnel transporta outra coisa. Inspecione-o em vez de assumir, e fixe-o ao entrar com --advertise-addr quando o padrão está errado. Um nó que anuncia um endereço que só ele alcança entra na mesma no swarm, e a falha aparece mais tarde como serviços que não conseguem falar entre locais.

Mudar o endereço anunciado mais tarde não é uma edição de configuração, porque o nó tem de sair e voltar a entrar.

Anote o endereço anunciado por nó nas suas notas, porque explica a maioria das falhas assimétricas.

O masquerade é o culpado habitual

Quando um gateway fica entre os nós e o túnel, o erro comum é aplicar masquerade a tudo o que sai da interface física. Isso também reescreve os endereços internos do overlay, pelo que cada par parece vir do gateway e os pares VXLAN deixam de se reconhecer. O resultado é tráfego encapsulado em falta ou unidirecional enquanto os pings simples continuam a funcionar.

Encaminhe o prefixo do overlay pelo gateway e deixe-o sem tradução. Se a tradução for realmente necessária para outro prefixo, limite-a a esse e nunca ao intervalo usado pelo 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

Verifique a ordem das regras e também o texto, porque um MASQUERADE largo mais cedo na cadeia vence uma exceção estreita mais tarde.

O VXLAN precisa de espaço no pacote

O VXLAN acrescenta 50 bytes às tramas que transporta. Uma camada inferior de 1500 bytes a transportar uma trama interna de 1500 bytes produz um pacote encapsulado que nenhum caminho entregará, e a falha parece uma descoberta de serviços intermitente e não um problema de tamanho. Ou baixa a MTU do túnel nas duas pontas ou define a MTU do overlay para que o controlador anuncie uma carga útil que caiba.

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

A rede ingress é criada automaticamente, por isso alterá-la significa removê-la e recriá-la em vez de a editar no local.

Se corrigir apenas um lado do túnel, a MTU menor continua a ser a que importa.

Observe o plano de dados, não os registos

Capture a porta VXLAN nas duas pontas. Tramas que saem de um lado e chegam ao outro significam que a camada inferior está bem e o problema está dentro do overlay. Tramas que saem e nunca chegam significam uma rota ou um filtro. Tramas que não saem de todo significam que o endereço de origem está errado.

Falhas de descoberta de serviços que desaparecem ao fim de alguns segundos apontam geralmente para o orçamento de pacotes ou um caminho instável, não para o quórum de raft.

Guarde a captura de uma janela a funcionar, porque compará-la com a avariada é mais rápido do que reler a configuração.