Docker Swarm su VPN: le attività girano, le chiamate tra servizi falliscono

Tre manager e cinque worker su due siti, uniti da un tunnel, e docker service ls mostra attività in esecuzione da entrambi i lati mentre le chiamate tra servizi scadono. Nulla nei log di Swarm sembra sbagliato. Questa combinazione è la firma di un problema nel piano dati: il piano di controllo ha trovato i nodi, e i frame incapsulati non hanno mai fatto il viaggio.

La mesh deve esistere prima dell'overlay

L'overlay di Swarm spinge i frame incapsulati direttamente tra gli indirizzi dei nodi, il che significa che ogni nodo ha bisogno di un indirizzo che ogni altro nodo possa raggiungere senza traduzione, sull'interfaccia fornita dal tunnel. Un tunnel che porta solo client a una porta pubblicata non basta. Il piano sottostante deve instradare da nodo a nodo in entrambe le direzioni.

Verificalo prima di toccare Swarm. Da ogni nodo, controlla la rotta verso l'indirizzo del tunnel di un pari, fai ping e poi prova la porta di controllo. Se il ping funziona e la porta no, il tunnel è a posto e c'è un filtro di mezzo.

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

Se la rotta punta all'interfaccia fisica invece di tun0 o wg0, l'overlay incapsulerà verso un indirizzo che il sito remoto non può raggiungere, e il sintomo sembrerà perdita di pacchetti.

Controlla quale indirizzo annuncia ogni nodo

Il demone annuncia un indirizzo e i pari lo usano per il piano dati. Su un host con più reti è facile annunciare l'indirizzo LAN o pubblico mentre il tunnel trasporta qualcos'altro. Ispezionalo invece di darlo per scontato, e fissalo al momento dell'adesione con --advertise-addr quando il valore predefinito è sbagliato. Un nodo che annuncia un indirizzo che solo lui raggiunge entra comunque nello swarm, e il guasto compare più tardi come servizi che non riescono a parlarsi tra siti.

Cambiare l'indirizzo annunciato più tardi non è una modifica di configurazione, perché il nodo deve uscire e rientrare.

Annota l'indirizzo annunciato per nodo nelle tue note, perché spiega la maggior parte dei guasti asimmetrici.

Il masquerade è il colpevole abituale

Quando un gateway si trova tra i nodi e il tunnel, l'errore comune è applicare masquerade a tutto ciò che esce dall'interfaccia fisica. Questo riscrive anche gli indirizzi interni dell'overlay, così ogni pari sembra arrivare dal gateway e i pari VXLAN smettono di riconoscersi. Il risultato è traffico incapsulato mancante o unidirezionale mentre i ping normali funzionano ancora.

Instrada il prefisso dell'overlay attraverso il gateway e lascialo non tradotto. Se la traduzione serve davvero per un altro prefisso, limitarla a quello e mai all'intervallo usato dall'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

Controlla l'ordine delle regole oltre al testo, perché un MASQUERADE ampio prima nella catena vince su un'eccezione stretta dopo.

VXLAN ha bisogno di spazio nel pacchetto

VXLAN aggiunge 50 byte ai frame che trasporta. Un piano sottostante da 1500 byte che trasporta un frame interno da 1500 byte produce un pacchetto incapsulato che nessun percorso consegnerà, e il guasto sembra una scoperta dei servizi intermittente più che un problema di dimensione. O abbassi l'MTU del tunnel a entrambe le estremità o imposti l'MTU dell'overlay in modo che il driver annunci un carico utile che ci sta.

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

La rete ingress viene creata automaticamente, quindi cambiarla significa rimuoverla e ricrearla invece di modificarla sul posto.

Se correggi solo un lato del tunnel, l'MTU più piccolo resta comunque quello che conta.

Osserva il piano dati, non i log

Cattura la porta VXLAN a entrambe le estremità. Frame che escono da un lato e arrivano dall'altro significano che il piano sottostante è a posto e il problema è dentro l'overlay. Frame che escono e non arrivano mai significano una rotta o un filtro. Frame che non escono affatto significano che l'indirizzo sorgente è sbagliato.

I guasti di scoperta dei servizi che si risolvono dopo pochi secondi di solito indicano il budget dei pacchetti o un percorso instabile, non il quorum di raft.

Conserva la cattura di una finestra funzionante, perché confrontarla con quella rotta è più veloce che rileggere la configurazione.