Kvifor GKE-podar ikkje når lokale vertar over VPN

Ping verkar frå noden og feilar frå poden, og ingenting kjem fram lokalt. Tunnelen og ruta er i orden; kjeldeadressa på kabelen er det ikkje. Det som skil dei to tilfella, er kva pakken påstår å vere når han forlèt klynga, og GKE har ei meining om det. Mekanismen er ei masquerade-unntaksliste, og det tek éin kommando å lese ho.

Les den gjeldande lista før du endrar noko

GKE leverer ein agent som avgjer, per destinasjonsområde, om pod-trafikk blir skriven om til nodeadressa på veg ut. Den medfølgjande konfigurasjonen nemner dei tre RFC1918-blokkene, 10.0.0.0/8, 172.16.0.0/12 og 192.168.0.0/16, som unntatte destinasjonar. Alt du sender frå ein pod til ein lokal 10.x-vert, forlèt derfor noden med poden si eiga adresse framleis fest. Trafikken til noden sjølv blir ikkje skriven om, og det er nettopp difor ping frå han verkar.

Les den tiltenkte konfigurasjonen og dei installerte reglane, for dei kan vere usamde. kubectl -n kube-system get configmap ip-masq-agent -o yaml viser kva agenten fekk beskjed om, og kubectl -n kube-system get pods -l k8s-app=ip-masq-agent viser om noko køyrer for å bruke det. På ein node viser iptables-save | grep -i masq reglane som faktisk finst i kjernen. Når ConfigMap seier éin ting og reglane noko anna, er agenten den mistenkte og ikkje nettet.

Stadfest kjeldeadressa med eit opptak

Ta eit opptak før du endrar ei liste. Eit filter på den eine destinasjonen held utskrifta lesbar: tcpdump -ni any host 10.20.30.40.

Samanlikn det med det den andre sida rapporterer. Eit opptak lokalt som viser pod-adressa og ingen svar, lukkar ringen: unntakslista forklarer asymmetrien utan nokon tunnelfeil. To observasjonar av éi kjeldeadresse er nok til å slutte å gjette om CNI-et.

Avgrens unntaket til pod-CIDR-et

Den støtta reparasjonen avgrensar unntaket i staden for å fjerne det: hald pod-CIDR-et unntatt og slepp resten av 10.x-rommet. Den lista bur i ConfigMap-en til agenten under nonMasqueradeCIDRs, og å endre ho er ei redigering etterfølgd av ein utrulling. Bytt ut den breie oppføringa med det faktiske pod-området til klynga, hald dei andre private blokkene om trafikk i klynga framleis treng dei, og lat resyncInterval vere med mindre du har ein grunn. Bruk det, stadfest at podane til agenten starta på nytt, og stadfest at kjernereglane endra seg.

Dette er ei endring for heile klynga med reell slagradius. Når ho er ute, kjem trafikk som før heldt pod-kjelda si no omskriven til noden, så alt som var nøkla til dei pod-adressene, ser ein annan avsendar. Ofra er loggar, tillatingslister og lokale brannmurreglar som namngir pod-adresser, og dei feilar stille. Kunngjer endringa som ei åtferdsendring, ikkje som ei retting.

I ei klynge med fleire node-pools, kontroller at agenten er planlagd på nodane der dei råka podane faktisk køyrer. Ein pool utan DaemonSet held på dei gamle reglane sine, og ingenting i ConfigMap vil vise det.

Alternativet og prisen

Det andre alternativet held pod-adressene intakte og lærer ruta om dei. Pod-CIDR-et går inn i trafikkveljarane til Cloud VPN, og den lokale sida treng ei returrute for det slik at svar veit kvar dei skal. Det bevarer pod-identiteten, som nokre tryggleiksmodellar ønskjer, og det utvidar både ruting- og brannmur-omfanget som den andre sida må godta.

Handelen er lesbarheit mot omfang. Omsetjing får den lokale sida til å sjå éi adresse per node, noko som er lett å setje på ei tillatingsliste og gøymer kva pod som sende kva. Inga omsetjing held pod-adressa ende-til-ende, noko som er betre for tilskriving og verre for kvar eining på ruta som må lære eit nytt område. Ingen av alternativa er ein Docker- eller CNI-defekt; begge er rutingsavgjerder med ein driftsrekning. Vel den rekninga teamet ditt kan betale, og skriv ned kvifor.

Stadfest og rull tilbake

Køyr det same opptaket igjen. Eit opptak på node-nivå som framleis skriv ut pod-adressa etter redigeringa di, betyr at reglane aldri endra seg, uansett kva ConfigMap seier. Kabelen er faktum; alt anna er slutning.

Kontroller deretter den motsette retninga, fordi halvparten av desse endringane berre blir stadfesta utgåande. Stadfest at svaret når noden eller poden som sende førespurnaden, og stadfest at applikasjonen vart ferdig i staden for berre å ta imot ein SYN. Eit opptak som viser ein førespurnad utan svar, er eit rutingsproblem på den andre sida, ikkje eit masquerade-problem på denne.

Tilbakerulling er den førre ConfigMap-en, brukt på same måte, med same stadfesting på at agenten starta på nytt og reglane endra seg. Ta vare på kjeldeadressa før og etter for éin kjend førespurnad i endringsloggen, sidan nettopp den eine lina beviser at endringa gjorde det du sa. GKE-veiledninga for IP-masquerade-agenten dokumenterer standardverdiane og ConfigMap-felta. Om kjeldeadressa er uendra etter utrullinga, køyrer ikkje agenten på den noden, og inga mengd YAML-redigering vil rette det.