Varför GKE-poddar inte når lokala värdar över VPN

Ping fungerar från noden och misslyckas från podden, och ingenting når fram lokalt. Tunneln och rutten är i ordning; källadressen på kabeln är det inte. Det som skiljer de två fallen är vad paketet påstår sig vara när det lämnar klustret, och GKE har en åsikt om det. Mekanismen är en masquerade-undantagslista, och det tar ett enda kommando att läsa den.

Läs den gällande listan innan du ändrar något

GKE levererar en agent som avgör, per destinationsintervall, om poddtrafik skrivs om till nodens adress på väg ut. Dess medföljande konfiguration namnger de tre RFC1918-blocken, 10.0.0.0/8, 172.16.0.0/12 och 192.168.0.0/16, som undantagna mål. Därför lämnar allt du skickar från en podd till en lokal 10.x-värd noden med poddens egen adress fortfarande fäst. Nodens egen trafik skrivs inte om, och det är just därför dess ping fungerar.

Läs den avsedda konfigurationen och de installerade reglerna, eftersom de kan vara oense. kubectl -n kube-system get configmap ip-masq-agent -o yaml visar vad agenten fick veta, och kubectl -n kube-system get pods -l k8s-app=ip-masq-agent visar om något körs för att tillämpa det. På en nod visar iptables-save | grep -i masq de regler som faktiskt finns i kärnan. När ConfigMap säger en sak och reglerna en annan är agenten den misstänkta, inte nätet.

Bekräfta källadressen med en fångst

Gör en fångst innan du ändrar en lista. Ett filter på det enda målet håller utdata läsbar: tcpdump -ni any host 10.20.30.40.

Jämför det med vad den andra sidan rapporterar. En fångst lokalt som visar poddens adress och inget svar sluter cirkeln: undantagslistan förklarar asymmetrin utan något tunnelfel. Två observationer av en och samma källadress räcker för att sluta gissa om CNI:n.

Begränsa undantaget till poddens CIDR

Den stödda reparationen begränsar undantaget i stället för att ta bort det: håll poddens CIDR undantagen och släpp resten av 10.x-rymden. Den listan bor i agentens ConfigMap under nonMasqueradeCIDRs, och att ändra den är en redigering följd av en utrullning. Byt ut den breda posten mot klustrets faktiska poddintervall, behåll de andra privata blocken om trafik inom klustret fortfarande behöver dem, och låt resyncInterval vara om du inte har en anledning. Tillämpa, bekräfta att agentens poddar startade om och bekräfta att kärnreglerna ändrades.

Det här är en ändring för hela klustret med verklig påverkan. När den väl är på plats anländer trafik som tidigare behöll sin poddkälla nu omskriven till noden, så allt som var nycklat till de poddadresserna ser en annan avsändare. Offren är loggar, tillåtelselistor och lokala brandväggsregler som namnger poddadresser, och de misslyckas tyst. Meddela ändringen som en beteendeändring, inte som en rättelse.

I ett kluster med flera nodpooler, kontrollera att agenten är schemalagd på de noder där de berörda poddarna faktiskt körs. En pool utan DaemonSet behåller sina gamla regler, och inget i ConfigMap kommer att visa det.

Alternativet och dess kostnad

Det andra alternativet håller poddadresserna intakta och lär rutten om dem. Poddens CIDR går in i Cloud VPN:s trafikväljare, och den lokala sidan behöver en returväg för den så att svar vet vart de ska. Det bevarar poddens identitet, som vissa säkerhetsmodeller vill ha, och det vidgar både routningens och brandväggens omfattning som den andra sidan måste acceptera.

Byten är läsbarhet mot omfattning. Översättning får den lokala sidan att se en adress per nod, vilket är lätt att sätta på en tillåtelselista och döljer vilken podd som skickade vad. Ingen översättning håller poddadressen hela vägen, vilket är bättre för attribution och sämre för varje enhet på vägen som måste lära sig ett nytt intervall. Inget av alternativen är en Docker- eller CNI-defekt; båda är routningsbeslut med en driftkostnad. Välj det som ditt team kan betala för, och skriv ner varför.

Verifiera och rulla tillbaka

Kör samma fångst igen. En fångst på nodnivå som fortfarande skriver ut poddens adress efter din redigering betyder att reglerna aldrig ändrades, vad ConfigMap än säger. Kabeln är faktum; allt annat är slutsats.

Kontrollera sedan den motsatta riktningen, eftersom hälften av dessa ändringar bara verifieras utåt. Bekräfta att svaret når den nod eller podd som skickade begäran, och bekräfta att applikationen blev klar i stället för att bara ta emot en SYN. En fångst som visar en begäran utan svar är ett routningsproblem på den andra sidan, inte ett masquerade-problem på den här.

Tillbakarullning är föregående ConfigMap, tillämpad på samma sätt, med samma bekräftelse att agenten startade om och reglerna ändrades. Behåll källadressen före och efter för en känd begäran i ändringsloggen, eftersom just den enda raden bevisar att ändringen gjorde det du sa. GKE:s guide för IP-masquerade-agenten dokumenterar standardvärdena och ConfigMap-fälten. Om källadressen är oförändrad efter utrullningen körs inte agenten på den noden, och ingen mängd YAML-redigering kommer att fixa det.