GKE-podar miste VPN-tilgang etter 1.14: to måtar å rette kjelda på

Etter 1.14 når podar VPN-en med eigne adresser, så peerar forkastar svar. Vel kjeldekontrakten, og set deretter nonMasqueradeCIDRs til å passe med han.

Ei oppgradering landar, og system på den andre sida av tunnelen byrjar å avvise pod-trafikk som fungerte veka før. Tunnelen er oppe, brannmurreglane er urørte, og ingen har redigert peer-policyen. Det som endra seg er usynleg i loggane til klynga: kjeldeadressa desse systema no ser. Det gapet forklarer ein feil som ser ut som eit nettverksutfall og oppfører seg som eit løyveproblem.

Det finst to gyldige svar, og dei fører deg til ulike stader. Vel kjeldekontrakten før du redigerer ein ConfigMap.

Standardregelen som slutta å bli installert

Tidlegare GKE-utgåver installerte ein masquerade-regel som erstatta pod-kjelder med nodeadressa kvar gong destinasjonen låg utanfor 10.0.0.0/8. Ein VPN-gateway innanfor det området såg pod-adressa, medan alt lenger borte såg ut som det kom frå noden. Peerar bygde løyvelister og returruter rundt nodeadresser fordi det var det dei observerte.

Seinare utgåver slutta å installere den standardregelen. Pod-trafikk kjem no til gatewayen med pod-adresser, uansett kva destinasjonen er. Ein peer som berre ruter nodeadresser, forkastar svara, og ingen av sidene skriv ei nyttig loggføring. Førespurnaden kan til og med lukkast i den fjerne enden, og det er det som gjer feilen forvirrande å jage.

Ingenting er øydelagt i tydinga ein daud komponent. Dei to sidene er rett og slett usamde om kva kjelde som er legitim.

Vel kjelda peer-en skal sjå

Å halde på pod-adresser er den meir presise kontrakten. Den fjerne sida ser arbeidslasta som produserte trafikken, loggføringa held seg ærleg, og policy per pod blir mogleg. Prisen er at peer-en må bera pod-prefikset.

Å halde på nodeadresser er den billegare kontrakten. Slå masquerading på att for den destinasjonen, og peer-en held fram med å sjå ei adresse han allereie stolar på.

Eitt spørsmål avgjer mellom dei: kva gjer peer-en med kjelda? Viss han loggar, brukar policy per kjelde eller handhevar trong returruting, rettferdiggjer pod-adresser den ekstra konfigurasjonen. Viss han berre treng å sende svar, kostar masquerading mindre og krev ingenting av den andre sida. Begge val er forsvarlege så lenge begge team skriv det ned.

Eit tredje alternativ er vanlegvis ein feil: masquerade alt og mist evna til å tilskrive trafikk. Unngå det med mindre ein peer verkeleg ikkje kan rute noko anna enn nodeadresser.

Pek nonMasqueradeCIDRs mot dei verkelege områda

GKE køyrer ip-masq-agent i kube-system, og ConfigMap-en hans listar opp destinasjonane som hoppar over masquerading. For å bevare pod-kjelder mot tunnelen høyrer pod-området, node-subnettet og det lokale prefikset alle heime på den lista.

Erstatt eksempelverdiane med område frå di eiga klynge. Ikkje gjer lista breiare enn kravet tilseier, fordi kvar ekstra oppføring endrar kva ein annan destinasjon ser. Dei tre oppføringane nedanfor 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

Ei oppføring på 0.0.0.0/0 slår av masquerading for alle destinasjonar, noko som endrar korleis urelaterte arbeidslaster framstår for eksterne tenester, og er sjeldan tilsikta. Agenten les konfigurasjonen sin på nytt ved resyncInterval, så ein omstart er vanlegvis unødvendig. Sjekk at agent-poden køyrer, og opne deretter den monterte fila inne i han. Det er lesinga av den fila som beviser at endringa kom fram.

Returvegen er den andre halvdelen

Masquerading endrar kjelda til førespurnaden og ingenting anna. Uansett kva kjelde peer-en får, treng han framleis ei rute tilbake til ho, og klynga treng framleis ei rute mot peer-en.

Eit opptak på VPN-gatewayen skil dei to feila raskt. Pakkar som kjem med pod-adresser og aldri får svar tyder at peer-en manglar ei rute for pod-prefikset. Eit svar som dukkar opp på gatewayen, men aldri når klynga, tyder at den lokale ruta manglar. Skriv kontrakten inn i saka uansett: kva kjelde peer-en ser, og kva prefiks han ruter tilbake.

Sjekk på nytt etter kvar oppgradering

Standardåtferda for masquerading har allereie endra seg éin gong, og utskifting av ein node-pool kan nullstille klyngenettverket. Handsame kjeldekontrakten som noko som skal verifiserast, ikkje antakast.

Etter ei oppgradering, send éin førespurnad frå ein pod til ei lokal teneste og les kjelda peer-en loggar. Den eine observasjonen fangar ein regresjon som ei tunnelstatusside gjerne vil rapportere som sunn. Å gjenta det kostar eitt minutt og sparer den neste personen ein kveld.

Relaterte artiklar