GKE-pods mistede VPN-adgang efter 1.14: to måder at rette kilden på

En opgradering lander, og systemer på den anden side af tunnelen begynder at afvise pod-trafik, som virkede i den foregående uge. Tunnelen er oppe, firewall-reglerne er urørte, og ingen har redigeret peer-politikken. Det, der ændrede sig, er usynligt i klyngens logfiler: kildeadressen, som disse systemer nu ser. Det gab forklarer en fejl, der ligner et netværksudfald og opfører sig som et tilladelsesproblem.

Der findes to gyldige svar, og de fører dig forskellige steder hen. Vælg kildekontrakten, før du redigerer en ConfigMap.

Standardreglen, som man holdt op med at installere

Tidligere GKE-udgivelser installerede en masquerade-regel, som erstattede pod-kilder med nodeadressen, når destinationen lå uden for 10.0.0.0/8. En VPN-gateway inden for det område så pod-adressen, mens alt længere væk så ud til at komme fra noden. Peers byggede allowlister og returruter omkring nodeadresser, fordi det var det, de observerede.

Senere udgivelser holdt op med at installere den standardregel. Pod-trafik ankommer nu til gatewayen med pod-adresser, uanset destinationen. En peer, der kun ruter nodeadresser, dropper svarene, og ingen af siderne skriver en brugbar logpost. Forespørgslen kan endda lykkes i den fjerne ende, og det er det, der gør fejlen forvirrende at jagte.

Intet er i stykker i betydningen en død komponent. De to sider er blot uenige om, hvilken kilde der er legitim.

Vælg den kilde, peer'en skal se

At beholde pod-adresser er den mere præcise kontrakt. Den fjerne side ser den arbejdsbyrde, der skabte trafikken, logføringen forbliver ærlig, og politik per pod bliver mulig. Prisen er, at peer'en skal bære pod-præfikset.

At beholde nodeadresser er den billigere kontrakt. Slå masquerading til igen for den destination, og peer'en bliver ved med at se en adresse, den allerede stoler på.

Et spørgsmål afgør valget: hvad gør peer'en med kilden? Hvis den logger, anvender politik per kilde eller håndhæver snæver returrouting, retfærdiggør pod-adresser den ekstra konfiguration. Hvis den kun skal sende svar, koster masquerading mindre og kræver intet af den anden side. Begge valg kan forsvares, så længe begge teams skriver det ned.

En tredje mulighed er som regel en fejl: masquerade alt og mist evnen til at tilskrive trafik. Undgå det, medmindre en peer virkelig ikke kan rute andet end nodeadresser.

Peg nonMasqueradeCIDRs mod de rigtige områder

GKE kører ip-masq-agent i kube-system, og dens ConfigMap lister de destinationer, der springer masquerading over. For at bevare pod-kilder mod tunnelen hører pod-området, node-subnettet og det lokale præfiks alle til på den liste.

Erstat eksempelværdierne med områder fra din egen klynge. Gør ikke listen bredere, end kravet tilsiger, fordi hver ekstra post ændrer, hvad en anden destination ser. De tre poster nedenfor står for pod-netværket, node-subnettet og præfikset bag tunnelen:

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

En post på 0.0.0.0/0 deaktiverer masquerading for alle destinationer, hvilket ændrer, hvordan ubeslægtede arbejdsbyrder fremstår for eksterne tjenester, og er sjældent tilsigtet. Agenten læser sin konfiguration igen ved resyncInterval, så en genstart er normalt unødvendig. Kontroller, at agentens pod kører, og åbn derefter den monterede fil inde i den. Det er læsningen af den fil, der beviser, at ændringen landede.

Returvejen er den anden halvdel

Masquerading ændrer forespørgslens kilde og intet andet. Uanset hvilken kilde peer'en modtager, har den stadig brug for en rute tilbage til den, og klyngen har stadig brug for en rute mod peer'en.

En optagelse på VPN-gatewayen skiller de to fejl hurtigt. Pakker, der ankommer med pod-adresser og aldrig får et svar, betyder, at peer'en mangler en rute til pod-præfikset. Et svar, der vises på gatewayen, men aldrig når klyngen, betyder, at den lokale rute mangler. Skriv kontrakten ind i sagen uanset hvad: hvilken kilde peer'en ser, og hvilket præfiks den ruter tilbage.

Tjek igen efter hver opgradering

Standardadfærden for masquerading har allerede ændret sig én gang, og udskiftning af en node-pulje kan nulstille klyngens netværk. Behandl kildekontrakten som noget, der skal verificeres, ikke antages.

Send efter en opgradering én forespørgsel fra en pod til en lokal tjeneste, og læs den kilde, peer'en logger. Den ene observation fanger en regression, som en tunnelstatusside gladeligt vil rapportere som sund. At gentage det koster et minut og sparer den næste person en aften.