Docker Swarm przez VPN: zadania działają, wywołania usług zawodzą

Trzej menedżerowie i pięciu pracowników w dwóch lokalizacjach, połączonych tunelem, a docker service ls pokazuje zadania działające po obu stronach, podczas gdy wywołania między usługami kończą się przekroczeniem czasu. Nic w logach Swarma nie wygląda źle. Ta kombinacja to sygnatura problemu w płaszczyźnie danych: płaszczyzna sterowania znalazła węzły, a hermetyzowane ramki nigdy nie odbyły podróży.

Sieć musi istnieć przed overlay

Overlay Swarma przepycha hermetyzowane ramki bezpośrednio między adresami węzłów, co oznacza, że każdy węzeł potrzebuje adresu, do którego każdy inny węzeł dotrze bez tłumaczenia, na interfejsie udostępnianym przez tunel. Tunel, który prowadzi tylko klientów do opublikowanego portu, nie wystarcza. Warstwa podkładowa musi routować od węzła do węzła w obu kierunkach.

Sprawdź to, zanim dotkniesz Swarma. Z każdego węzła sprawdź trasę do adresu tunelu partnera, spinguj go, a następnie przetestuj port sterujący. Jeśli ping działa, a port nie, tunel jest w porządku i filtr stoi na drodze.

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

Jeśli trasa wskazuje interfejs fizyczny zamiast tun0 lub wg0, overlay zahamuje do adresu, którego zdalna lokalizacja nie osiągnie, a objaw będzie wyglądał jak utrata pakietów.

Sprawdź, jaki adres ogłasza każdy węzeł

Demon ogłasza jeden adres, a partnerzy używają go w płaszczyźnie danych. Na hoście z wieloma sieciami łatwo ogłosić adres LAN lub publiczny, podczas gdy tunel niesie coś innego. Zbadaj go, zamiast zakładać, i przypnij przy dołączaniu za pomocą --advertise-addr, gdy domyślny jest błędny. Węzeł ogłaszający adres osiągalny tylko dla niego nadal dołącza do swarmu, a awaria ujawnia się później jako usługi, które nie mogą się komunikować między lokalizacjami.

Zmiana ogłoszonego adresu później nie jest edycją konfiguracji, ponieważ węzeł musi opuścić klaster i dołączyć ponownie.

Zapisz ogłoszony adres dla każdego węzła w notatkach, bo wyjaśnia to większość asymetrycznych awarii.

Masquerade to zwykły winowajca

Gdy brama stoi między węzłami a tunelem, częstym błędem jest stosowanie masquerade do wszystkiego, co wychodzi z interfejsu fizycznego. To przepisuje również wewnętrzne adresy overlaya, więc każdy partner wygląda, jakby przychodził z bramy, a partnerzy VXLAN przestają się rozpoznawać. Wynikiem jest brakujący lub jednokierunkowy hermetyzowany ruch, podczas gdy zwykłe pingi nadal działają.

Routuj prefiks overlaya przez bramę i pozostaw go nieprzetłumaczony. Jeśli tłumaczenie jest naprawdę potrzebne dla innego prefiksu, ogranicz je do niego i nigdy do zakresu używanego przez 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

Sprawdź kolejność reguł, jak i ich treść, bo szerokie MASQUERADE wcześniej w łańcuchu wygrywa z wąskim wyjątkiem później.

VXLAN potrzebuje miejsca w pakiecie

VXLAN dodaje 50 bajtów do przenoszonych ramek. Warstwa podkładowa 1500 bajtów przenosząca wewnętrzną ramkę 1500 bajtów tworzy hermetyzowany pakiet, którego żadna ścieżka nie dostarczy, a awaria wygląda jak przerywane wykrywanie usług, a nie problem z rozmiarem. Albo obniż MTU tunelu na obu końcach, albo ustaw MTU overlaya tak, aby sterownik ogłaszał mieszczący się ładunek.

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

Sieć ingress jest tworzona automatycznie, więc jej zmiana oznacza usunięcie i ponowne utworzenie, a nie edycję w miejscu.

Jeśli naprawisz tylko jedną stronę tunelu, mniejsze MTU nadal pozostaje tym, które ma znaczenie.

Obserwuj płaszczyznę danych, a nie logi

Przechwyć port VXLAN na obu końcach. Ramki wychodzące z jednej strony i docierające na drugą oznaczają, że warstwa podkładowa jest w porządku, a problem jest wewnątrz overlaya. Ramki wychodzące i nigdy niedocierające oznaczają trasę lub filtr. Ramki, które w ogóle nie wychodzą, oznaczają, że adres źródłowy jest błędny.

Awarie wykrywania usług, które ustępują po kilku sekundach, zwykle wskazują na budżet pakietów lub niestabilną ścieżkę, a nie na kworum raft.

Zachowaj przechwycenie z działającego okna, bo porównanie go z zepsutym jest szybsze niż ponowne czytanie konfiguracji.