Waarom GKE-pods geen lokale hosts bereiken via VPN

Ping werkt vanaf de node en faalt vanaf de pod, en lokaal komt niets aan. De tunnel en de route zijn in orde; het bronadres op de draad niet. Wat de twee gevallen onderscheidt, is wat het pakket beweert te zijn wanneer het het cluster verlaat, en GKE heeft daar een mening over. Het mechanisme is een masquerade-uitzonderingslijst, en die lezen kost één commando.

Lees de effectieve lijst voordat je iets wijzigt

GKE levert een agent die per bestemmingsbereik beslist of podverkeer bij het naar buiten gaan wordt herschreven naar het nodeadres. De meegeleverde configuratie noemt de drie RFC1918-blokken, 10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16, als uitgezonderde bestemmingen. Alles wat je van een pod naar een lokale 10.x-host stuurt, verlaat de node dus met het eigen adres van de pod er nog aan. Het verkeer van de node zelf wordt niet herschreven, en dat is precies waarom zijn ping werkt.

Lees de bedoelde configuratie en de geïnstalleerde regels, want die kunnen van elkaar afwijken. kubectl -n kube-system get configmap ip-masq-agent -o yaml toont wat de agent is verteld, en kubectl -n kube-system get pods -l k8s-app=ip-masq-agent toont of er iets draait om het toe te passen. Op een node toont iptables-save | grep -i masq de regels die echt in de kernel staan. Als de ConfigMap het ene zegt en de regels het andere, is de agent de verdachte en niet het netwerk.

Bevestig het bronadres met een capture

Maak een capture voordat je een lijst wijzigt. Een filter op de enige bestemming houdt de uitvoer leesbaar: tcpdump -ni any host 10.20.30.40.

Vergelijk dat met wat de andere kant meldt. Een capture lokaal die het podadres toont en geen antwoord, sluit de cirkel: de uitzonderingslijst verklaart de asymmetrie zonder enige tunnelstoring. Twee waarnemingen van één bronadres zijn genoeg om op te houden met gissen over de CNI.

Vernauw de uitzondering tot de pod-CIDR

De ondersteunde reparatie vernauwt de uitzondering in plaats van hem te verwijderen: houd de pod-CIDR uitgezonderd en laat de rest van de 10.x-ruimte vallen. Die lijst staat in de ConfigMap van de agent onder nonMasqueradeCIDRs, en hem wijzigen is een bewerking gevolgd door een rollout. Vervang de brede vermelding door het werkelijke podbereik van het cluster, houd de andere privéblokken als verkeer binnen het cluster ze nog nodig heeft, en laat resyncInterval met rust tenzij je een reden hebt. Pas het toe, bevestig dat de pods van de agent opnieuw zijn gestart en bevestig dat de kernelregels zijn gewijzigd.

Dit is een wijziging voor het hele cluster met een echte impactradius. Zodra die erdoor is, komt verkeer dat voorheen zijn podbron behield nu herschreven naar de node aan, dus alles wat op die podadressen was gebaseerd, ziet een andere afzender. De slachtoffers zijn logs, toelatingslijsten en lokale firewallregels die podadressen noemen, en ze falen stil. Kondig de wijziging aan als een gedragswijziging, niet als een correctie.

Controleer in een cluster met meerdere nodepools of de agent is ingepland op de nodes waar de getroffen pods echt draaien. Een pool zonder de DaemonSet houdt zijn oude regels, en niets in de ConfigMap zal dat tonen.

Het alternatief en de prijs

De andere optie houdt podadressen intact en leert het pad erover. De pod-CIDR gaat in de verkeersselectors van Cloud VPN, en de lokale kant heeft er een retourroute voor nodig zodat antwoorden weten waar ze heen moeten. Dat behoudt de podidentiteit, die sommige beveiligingsmodellen willen, en het verbreedt zowel de routing- als de firewallscope die de andere kant moet accepteren.

De ruil is leesbaarheid tegen scope. Vertaling laat de lokale kant één adres per node zien, wat makkelijk op een toelatingslijst te zetten is en verbergt welke pod wat stuurde. Geen vertaling houdt het podadres van begin tot eind, wat beter is voor toerekening en slechter voor elk apparaat op het pad dat een nieuw bereik moet leren. Geen van beide opties is een Docker- of CNI-defect; beide zijn routingbeslissingen met een operationele rekening. Kies degene waarvan je team de rekening kan betalen, en schrijf op waarom.

Verifieer en draai terug

Voer dezelfde capture opnieuw uit. Een capture op nodeniveau die na je bewerking nog steeds het podadres toont, betekent dat de regels nooit zijn gewijzigd, wat de ConfigMap ook zegt. De draad is het feit; al het andere is gevolgtrekking.

Controleer daarna de tegenovergestelde richting, want de helft van deze wijzigingen wordt alleen uitgaand geverifieerd. Bevestig dat het antwoord de node of pod bereikt die het verzoek stuurde, en bevestig dat de toepassing klaar was in plaats van alleen een SYN te ontvangen. Een capture die een verzoek zonder antwoord toont, is een routingprobleem aan de andere kant, geen masqueradeprobleem aan deze.

Terugdraaien is de vorige ConfigMap, op dezelfde manier toegepast, met dezelfde bevestiging dat de agent opnieuw is gestart en de regels zijn gewijzigd. Bewaar het bronadres voor en na voor één bekend verzoek in het wijzigingsrecord, want juist die ene regel bewijst dat de wijziging deed wat je zei. De GKE-handleiding voor de IP-masquerade-agent documenteert de standaardwaarden en de ConfigMap-velden. Als het bronadres na de rollout ongewijzigd is, draait de agent niet op die node en geen enkele YAML-bewerking lost dat op.