Dlaczego pody GKE nie docierają do lokalnych hostów przez VPN

Ping działa z węzła i zawodzi z poda, a lokalnie nic nie dociera. Tunel i trasa są w porządku; adres źródłowy na drucie nie. Tym, co różni te dwa przypadki, jest to, za co pakiet się podaje, opuszczając klaster, a GKE ma na ten temat zdanie. Mechanizmem jest lista wyjątków masquerade, a jej przeczytanie wymaga jednego polecenia.

Przeczytaj obowiązującą listę, zanim cokolwiek zmienisz

GKE dostarcza agenta, który dla każdego zakresu docelowego decyduje, czy ruch podów ma być przy wyjściu przepisany na adres węzła. Jego domyślna konfiguracja wymienia trzy bloki RFC1918, 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16, jako cele wyłączone. Dlatego wszystko, co wyślesz z poda do lokalnego hosta 10.x, opuszcza węzeł z wciąż przypiętym adresem samego poda. Ruch samego węzła nie jest przepisywany i właśnie dlatego jego ping działa.

Przeczytaj zamierzoną konfigurację i zainstalowane reguły, bo mogą się nie zgadzać. kubectl -n kube-system get configmap ip-masq-agent -o yaml pokazuje, co powiedziano agentowi, a kubectl -n kube-system get pods -l k8s-app=ip-masq-agent pokazuje, czy coś działa, by to zastosować. Na węźle iptables-save | grep -i masq pokazuje reguły, które naprawdę istnieją w jądrze. Gdy ConfigMap mówi jedno, a reguły drugie, podejrzanym jest agent, a nie sieć.

Potwierdź adres źródłowy przechwyceniem

Zrób przechwycenie, zanim zmienisz listę. Filtr na jednym celu utrzymuje czytelne wyjście: tcpdump -ni any host 10.20.30.40.

Porównaj to z tym, co raportuje druga strona. Przechwycenie lokalnie, które pokazuje adres poda i brak odpowiedzi, zamyka pętlę: lista wyjątków wyjaśnia asymetrię bez żadnej usterki tunelu. Dwie obserwacje jednego adresu źródłowego wystarczą, by przestać zgadywać o CNI.

Zawęź wyjątek do CIDR podów

Wspierana naprawa zawęża wyjątek zamiast go usuwać: zostaw CIDR podów wyłączony i odrzuć resztę przestrzeni 10.x. Ta lista mieszka w ConfigMap agenta pod nonMasqueradeCIDRs, a jej zmiana to edycja, po której następuje wdrożenie. Zastąp szeroki wpis rzeczywistym zakresem podów klastra, zachowaj pozostałe bloki prywatne, jeśli ruch wewnątrz klastra nadal ich potrzebuje, i zostaw resyncInterval w spokoju, chyba że masz powód. Zastosuj, potwierdź, że pody agenta się zrestartowały, i potwierdź, że reguły jądra się zmieniły.

To zmiana w całym klastrze o realnym zasięgu. Po jej wdrożeniu ruch, który wcześniej zachowywał źródło poda, dociera teraz przepisany na węzeł, więc wszystko, co opierało się na tych adresach podów, widzi innego nadawcę. Ofiarami są logi, listy dozwolonych i lokalne reguły firewalla, które wymieniają adresy podów, i zawodzą po cichu. Ogłoś zmianę jako zmianę zachowania, nie jako poprawkę.

W klastrze z kilkoma pulami węzłów sprawdź, czy agent jest zaplanowany na węzłach, na których naprawdę działają dotknięte pody. Pula bez DaemonSet zachowuje swoje stare reguły i nic w ConfigMap tego nie pokaże.

Alternatywa i jej koszt

Druga opcja pozostawia adresy podów nietknięte i uczy trasę o nich. CIDR podów trafia do selektorów ruchu Cloud VPN, a strona lokalna potrzebuje dla niego trasy powrotnej, żeby odpowiedzi wiedziały, dokąd iść. To zachowuje tożsamość poda, której chcą niektóre modele bezpieczeństwa, i poszerza zarówno zakres routingu, jak i zakres firewalla, który druga strona musi zaakceptować.

Handel to czytelność przeciw zasięgowi. Tłumaczenie sprawia, że strona lokalna widzi jeden adres na węzeł, co łatwo wpisać na listę dozwolonych i co ukrywa, który pod co wysłał. Bez tłumaczenia adres poda jest zachowany od końca do końca, co jest lepsze dla przypisania, a gorsze dla każdego urządzenia na trasie, które musi nauczyć się nowego zakresu. Żadna z opcji nie jest defektem Dockera ani CNI; obie są decyzjami routingu z rachunkiem operacyjnym. Wybierz tę, której rachunek twój zespół może zapłacić, i zapisz dlaczego.

Zweryfikuj i wycofaj

Uruchom to samo przechwycenie ponownie. Przechwycenie na poziomie węzła, które po twojej edycji nadal wypisuje adres poda, oznacza, że reguły nigdy się nie zmieniły, cokolwiek mówi ConfigMap. Drut jest faktem; wszystko inne to wnioskowanie.

Następnie sprawdź kierunek odwrotny, bo połowa tych zmian jest weryfikowana tylko na wyjściu. Potwierdź, że odpowiedź dociera do węzła lub poda, który wysłał żądanie, i potwierdź, że aplikacja zakończyła się, a nie tylko odebrała SYN. Przechwycenie pokazujące żądanie bez odpowiedzi to problem routingu po drugiej stronie, nie problem masquerade po tej.

Wycofanie to poprzedni ConfigMap, zastosowany w ten sam sposób, z tym samym potwierdzeniem, że agent się zrestartował, a reguły zmieniły. Zachowaj adres źródłowy przed i po dla jednego znanego żądania w rejestrze zmian, bo właśnie ta jedna linia dowodzi, że zmiana zrobiła to, co powiedziałeś. Przewodnik GKE po agencie masquerade IP dokumentuje wartości domyślne i pola ConfigMap. Jeśli adres źródłowy po wdrożeniu się nie zmienił, agent nie działa na tym węźle i żadna edycja YAML tego nie naprawi.