GKE-pods verloren na 1.14 de VPN-toegang: twee manieren om de bron te repareren

Er komt een upgrade, en systemen aan de andere kant van de tunnel beginnen podverkeer te weigeren dat de week ervoor nog werkte. De tunnel staat, de firewallregels zijn onaangeroerd en niemand heeft het peerbeleid bewerkt. Wat veranderd is, is onzichtbaar in de clusterlogs: het bronadres dat die systemen nu zien. Die kloof verklaart een storing die op een netwerkstoring lijkt en zich als een rechtenprobleem gedraagt.

Er bestaan twee geldige antwoorden, en ze sturen je naar verschillende plekken. Kies het broncontract voordat je een ConfigMap bewerkt.

De standaardregel die niet meer werd geïnstalleerd

Eerdere GKE-releases installeerden een masquerade-regel die podbronnen verving door het nodeadres wanneer de bestemming buiten 10.0.0.0/8 lag. Een VPN-gateway binnen dat bereik zag het podadres, terwijl alles verder weg leek te komen van de node. Peers bouwden allowlists en retourroutes rond nodeadressen, omdat ze dat nou eenmaal zagen.

Latere releases stopten met het installeren van die standaardregel. Podverkeer komt nu bij de gateway aan met podadressen, wat de bestemming ook is. Een peer die alleen nodeadressen routeert, laat de antwoorden vallen, en geen van beide kanten schrijft een bruikbare logregel. Het verzoek kan aan de verre kant zelfs slagen, en dat maakt de storing verwarrend om te achtervolgen.

Niets is kapot in de zin van een dode component. Beide kanten zijn het simpelweg oneens over welke bron legitiem is.

Kies de bron die de peer zou moeten zien

Podadressen behouden is het nauwkeuriger contract. De verre kant ziet de workload die het verkeer produceerde, de logging blijft eerlijk en beleid per pod wordt mogelijk. De prijs is dat de peer het pod-prefix moet dragen.

Nodeadressen behouden is het goedkopere contract. Zet masquerading voor die bestemming weer aan en de peer blijft een adres zien dat hij al vertrouwt.

Eén vraag beslist tussen beide: wat doet de peer met de bron? Als hij logt, beleid per bron toepast of nauwe retourroutering afdwingt, rechtvaardigen podadressen de extra configuratie. Als hij alleen antwoorden hoeft te sturen, kost masquerading minder en vraagt het niets van de andere kant. Beide keuzes zijn verdedigbaar zolang beide teams het opschrijven.

Een derde optie is meestal een fout: alles masqueraden en het vermogen verliezen om verkeer toe te schrijven. Vermijd het, tenzij een peer echt niets anders kan routeren dan nodeadressen.

Wijs nonMasqueradeCIDRs naar de echte bereiken

GKE draait de ip-masq-agent in kube-system, en de ConfigMap ervan somt de bestemmingen op die masquerading overslaan. Om podbronnen richting de tunnel te bewaren, horen het podbereik, het nodesubnet en het lokale prefix allemaal in die lijst.

Vervang de voorbeeldwaarden door bereiken uit je eigen cluster. Maak de lijst niet breder dan de eis voorschrijft, want elke extra vermelding verandert wat een andere bestemming ziet. De drie vermeldingen hieronder staan voor het podnetwerk, het nodesubnet en het prefix achter de tunnel:

nonMasqueradeCIDRs:
  - 10.12.0.0/14
  - 10.100.0.0/16
  - 172.16.0.0/12
masqLinkLocal: false
resyncInterval: 60s

Een vermelding van 0.0.0.0/0 schakelt masquerading voor alle bestemmingen uit, wat verandert hoe ongerelateerde workloads er voor externe diensten uitzien en zelden de bedoeling is. De agent herleest zijn configuratie op resyncInterval, dus een herstart is meestal niet nodig. Controleer of de agentpod draait en open daarna het gemounte bestand erin. Het lezen van dat bestand is wat bewijst dat de wijziging is aangekomen.

Het retourpad is de andere helft

Masquerading verandert de bron van het verzoek en niets anders. Welke bron de peer ook ontvangt, hij heeft er nog steeds een route naar terug nodig, en het cluster heeft nog steeds een route richting de peer nodig.

Een capture op de VPN-gateway scheidt de twee storingen snel. Pakketten die met podadressen aankomen en nooit een antwoord krijgen, betekenen dat de peer geen route heeft voor het pod-prefix. Een antwoord dat op de gateway verschijnt maar het cluster nooit bereikt, betekent dat de lokale route ontbreekt. Schrijf het contract hoe dan ook in de ticket: welke bron de peer ziet, en naar welk prefix hij terug routeert.

Controleer opnieuw na elke upgrade

Het standaardgedrag van masquerading is al eens veranderd, en het vervangen van een nodepool kan de clusternetwerkconfiguratie resetten. Behandel het broncontract als iets om te verifiëren, niet om aan te nemen.

Stuur na een upgrade één verzoek van een pod naar een lokale dienst en lees de bron die de peer logt. Die ene observatie vangt een regressie die een tunnelstatuspagina graag als gezond zou melden. Het herhalen kost een minuut en bespaart de volgende persoon een avond.