GKE-pods mistet VPN-tilgang etter 1.14: to måter å rette kilden på

En oppgradering lander, og systemer på den andre siden av tunnelen begynner å avvise pod-trafikk som fungerte uken før. Tunnelen er oppe, brannmurreglene er urørt, og ingen har redigert peer-policyen. Det som endret seg er usynlig i klyngens logger: kildeadressen disse systemene nå ser. Det gapet forklarer en feil som ser ut som et nettverksutfall og oppfører seg som et tillatelsesproblem.

Det finnes to gyldige svar, og de fører deg til forskjellige steder. Velg kildekontrakten før du redigerer en ConfigMap.

Standardregelen som sluttet å bli installert

Tidligere GKE-utgivelser installerte en masquerade-regel som erstattet pod-kilder med nodeadressen hver gang destinasjonen lå utenfor 10.0.0.0/8. En VPN-gateway innenfor det området så pod-adressen, mens alt lenger borte så ut som det kom fra noden. Peers bygde tillatelseslister og returruter rundt nodeadresser fordi det var det de observerte.

Senere utgivelser sluttet å installere den standardregelen. Pod-trafikk kommer nå til gatewayen med pod-adresser, uansett hva destinasjonen er. En peer som bare ruter nodeadresser, forkaster svarene, og ingen av sidene skriver en nyttig loggføring. Forespørselen kan til og med lykkes i den fjerne enden, og det er det som gjør feilen forvirrende å jakte på.

Ingenting er ødelagt i betydningen en død komponent. De to sidene er rett og slett uenige om hvilken kilde som er legitim.

Velg kilden peer-en skal se

Å beholde pod-adresser er den mer presise kontrakten. Den fjerne siden ser arbeidsbelastningen som produserte trafikken, loggføringen forblir ærlig, og policy per pod blir mulig. Prisen er at peer-en må bære pod-prefikset.

Å beholde nodeadresser er den billigere kontrakten. Slå masquerading på igjen for den destinasjonen, og peer-en fortsetter å se en adresse den allerede stoler på.

Ett spørsmål avgjør mellom dem: hva gjør peer-en med kilden? Hvis den logger, anvender policy per kilde eller håndhever snever returruting, rettferdiggjør pod-adresser den ekstra konfigurasjonen. Hvis den bare trenger å sende svar, koster masquerading mindre og krever ingenting av den andre siden. Begge valg er forsvarlige så lenge begge team skriver det ned.

Et tredje alternativ er vanligvis en feil: masquerade alt og mist evnen til å tilskrive trafikk. Unngå det med mindre en peer virkelig ikke kan rute noe annet enn nodeadresser.

Pek nonMasqueradeCIDRs mot de virkelige områdene

GKE kjører ip-masq-agent i kube-system, og ConfigMap-en dens lister opp destinasjonene som hopper over masquerading. For å bevare pod-kilder mot tunnelen hører pod-området, node-subnettet og det lokale prefikset alle hjemme på den listen.

Erstatt eksempelverdiene med områder fra din egen klynge. Ikke gjør listen bredere enn kravet tilsier, fordi hver ekstra oppføring endrer hva en annen destinasjon ser. De tre oppføringene nedenfor står for pod-nettverket, node-subnettet og prefikset bak tunnelen:

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

En oppføring på 0.0.0.0/0 deaktiverer masquerading for alle destinasjoner, noe som endrer hvordan urelaterte arbeidsbelastninger fremstår for eksterne tjenester, og er sjelden tilsiktet. Agenten leser konfigurasjonen sin på nytt ved resyncInterval, så en omstart er vanligvis unødvendig. Sjekk at agent-poden kjører, og åpne deretter den monterte filen inne i den. Det er lesingen av den filen som beviser at endringen kom frem.

Returveien er den andre halvdelen

Masquerading endrer forespørselens kilde og ingenting annet. Uansett hvilken kilde peer-en mottar, trenger den fortsatt en rute tilbake til den, og klyngen trenger fortsatt en rute mot peer-en.

Et opptak på VPN-gatewayen skiller de to feilene raskt. Pakker som kommer med pod-adresser og aldri får svar betyr at peer-en mangler en rute for pod-prefikset. Et svar som dukker opp på gatewayen, men aldri når klyngen, betyr at den lokale ruten mangler. Skriv kontrakten inn i saken uansett: hvilken kilde peer-en ser, og hvilket prefiks den ruter tilbake.

Sjekk på nytt etter hver oppgradering

Standardoppførselen for masquerading har allerede endret seg én gang, og utskifting av en node-pool kan nullstille klyngenettverket. Behandle kildekontrakten som noe som skal verifiseres, ikke antas.

Etter en oppgradering, send én forespørsel fra en pod til en lokal tjeneste og les kilden peer-en logger. Den ene observasjonen fanger en regresjon som en tunnelstatusside gjerne vil rapportere som sunn. Å gjenta det koster ett minutt og sparer den neste personen en kveld.