Hvorfor GKE-poder ikke når lokale verter over VPN

Ping virker fra noden og feiler fra poden, og ingenting kommer frem lokalt. Tunnelen og ruten er i orden; kildeadressen på kabelen er det ikke. Det som skiller de to tilfellene, er hva pakken påstår å være når den forlater klyngen, og GKE har en mening om det. Mekanismen er en masquerade-unntaksliste, og det tar én kommando å lese den.

Les den gjeldende listen før du endrer noe

GKE leverer en agent som avgjør, per destinasjonsområde, om pod-trafikk skrives om til nodens adresse på vei ut. Dens medfølgende konfigurasjon nevner de tre RFC1918-blokkene, 10.0.0.0/8, 172.16.0.0/12 og 192.168.0.0/16, som unntatte destinasjoner. Alt du sender fra en pod til en lokal 10.x-vert, forlater derfor noden med podens egen adresse fortsatt festet. Nodens egen trafikk skrives ikke om, og det er nettopp derfor ping fra den virker.

Les den tiltenkte konfigurasjonen og de installerte reglene, for de kan være uenige. kubectl -n kube-system get configmap ip-masq-agent -o yaml viser hva agenten fikk beskjed om, og kubectl -n kube-system get pods -l k8s-app=ip-masq-agent viser om noe kjører for å anvende det. På en node viser iptables-save | grep -i masq reglene som faktisk finnes i kjernen. Når ConfigMap sier én ting og reglene noe annet, er agenten den mistenkte og ikke nettet.

Bekreft kildeadressen med et opptak

Ta et opptak før du endrer en liste. Et filter på den ene destinasjonen holder utskriften lesbar: tcpdump -ni any host 10.20.30.40.

Sammenlign det med det den andre siden rapporterer. Et opptak lokalt som viser pod-adressen og ingen svar, lukker ringen: unntakslisten forklarer asymmetrien uten noen tunnelfeil. To observasjoner av én kildeadresse er nok til å slutte å gjette om CNI-et.

Begrens unntaket til pod-CIDR-et

Den støttede reparasjonen begrenser unntaket i stedet for å fjerne det: hold pod-CIDR-et unntatt og slipp resten av 10.x-rommet. Den listen bor i agentens ConfigMap under nonMasqueradeCIDRs, og å endre den er en redigering etterfulgt av en utrulling. Bytt ut den brede oppføringen med klyngens faktiske pod-område, behold de andre private blokkene hvis trafikk i klyngen fortsatt trenger dem, og la resyncInterval være med mindre du har en grunn. Bruk det, bekreft at agentens pod-er startet på nytt, og bekreft at kjernereglene endret seg.

Dette er en endring for hele klyngen med reell slagradius. Når den er ute, ankommer trafikk som før beholdt pod-kilden sin nå omskrevet til noden, så alt som var nøklet til de pod-adressene, ser en annen avsender. Ofrene er logger, tillatelseslister og lokale brannmurregler som navngir pod-adresser, og de feiler stille. Kunngjør endringen som en atferdsendring, ikke som en rettelse.

I en klynge med flere node-pools, kontroller at agenten er planlagt på nodene der de berørte pod-ene faktisk kjører. En pool uten DaemonSet beholder sine gamle regler, og ingenting i ConfigMap vil vise det.

Alternativet og prisen

Det andre alternativet holder pod-adressene intakte og lærer ruten om dem. Pod-CIDR-et går inn i Cloud VPNs trafikkvelgere, og den lokale siden trenger en returrute for det slik at svar vet hvor de skal. Det bevarer pod-identiteten, som noen sikkerhetsmodeller ønsker, og det utvider både rutings- og brannmur-omfanget som den andre siden må godta.

Handelen er lesbarhet mot omfang. Oversettelse får den lokale siden til å se én adresse per node, noe som er lett å sette på en tillatelsesliste og skjuler hvilken pod som sendte hva. Ingen oversettelse holder pod-adressen ende-til-ende, noe som er bedre for tilskrivning og verre for hver enhet på ruten som må lære et nytt område. Ingen av alternativene er en Docker- eller CNI-defekt; begge er rutingsbeslutninger med en driftsregning. Velg den regningen teamet ditt kan betale, og skriv ned hvorfor.

Verifiser og rull tilbake

Kjør det samme opptaket igjen. Et opptak på node-nivå som fortsatt skriver ut pod-adressen etter redigeringen din, betyr at reglene aldri endret seg, uansett hva ConfigMap sier. Kabelen er faktum; alt annet er slutning.

Kontroller deretter den motsatte retningen, fordi halvparten av disse endringene bare verifiseres utgående. Bekreft at svaret når noden eller pod-en som sendte forespørselen, og bekreft at applikasjonen ble ferdig i stedet for bare å motta en SYN. Et opptak som viser en forespørsel uten svar, er et rutingsproblem på den andre siden, ikke et masquerade-problem på denne.

Tilbakerulling er den forrige ConfigMap, brukt på samme måte, med samme bekreftelse på at agenten startet på nytt og reglene endret seg. Ta vare på kildeadressen før og etter for én kjent forespørsel i endringsloggen, siden nettopp den ene linjen beviser at endringen gjorde det du sa. GKE-veiledningen for IP-masquerade-agenten dokumenterer standardverdiene og ConfigMap-feltene. Hvis kildeadressen er uendret etter utrullingen, kjører ikke agenten på den noden, og ingen mengde YAML-redigering vil rette det.