Hvorfor GKE-pods ikke kan nå lokale værter over VPN

Ping virker fra noden og fejler fra podden, og intet når frem lokalt. Tunnelen og ruten er i orden; kildeadressen på kablet er det ikke. Det, der adskiller de to tilfælde, er, hvad pakken påstår at være, når den forlader klyngen, og GKE har en mening om det. Mekanismen er en masquerade-undtagelsesliste, og det tager én kommando at læse den.

Læs den gældende liste, før du ændrer noget

GKE leverer en agent, der for hvert destinationsområde afgør, om pod-trafik omskrives til nodens adresse på vej ud. Dens medfølgende konfiguration angiver de tre RFC1918-blokke, 10.0.0.0/8, 172.16.0.0/12 og 192.168.0.0/16, som undtagne destinationer. Alt, hvad du sender fra en pod til en lokal 10.x-vært, forlader derfor noden med poddens egen adresse stadig påklistret. Nodens egen trafik omskrives ikke, og det er netop derfor, dens ping virker.

Læs den tilsigtede konfiguration og de installerede regler, for de kan være uenige. kubectl -n kube-system get configmap ip-masq-agent -o yaml viser, hvad agenten fik at vide, og kubectl -n kube-system get pods -l k8s-app=ip-masq-agent viser, om der kører noget, der anvender det. På en node viser iptables-save | grep -i masq de regler, der faktisk findes i kernen. Når ConfigMap siger ét og reglerne noget andet, er agenten den mistænkte frem for netværket.

Bekræft kildeadressen med en optagelse

Optag, før du ændrer en liste. Et filter på den ene destination holder outputtet læsbart: tcpdump -ni any host 10.20.30.40.

Sammenlign det med, hvad den anden side rapporterer. En optagelse lokalt, der viser pod-adressen og intet svar, lukker ringen: undtagelseslisten forklarer asymmetrien uden nogen tunnel-fejl. To observationer af én kildeadresse er nok til at holde op med at gætte om CNI'et.

Indsnævr undtagelsen til pod-CIDR'et

Den understøttede reparation indsnævrer undtagelsen i stedet for at fjerne den: hold pod-CIDR'et undtaget og slip resten af 10.x-rummet. Den liste ligger i agentens ConfigMap under nonMasqueradeCIDRs, og at ændre den er en redigering efterfulgt af en udrulning. Erstat den brede post med klyngens faktiske pod-område, behold de andre private blokke, hvis trafik i klyngen stadig har brug for dem, og lad resyncInterval være, medmindre du har en grund. Anvend det, bekræft at agentens pods er genstartet, og bekræft at kernel-reglerne er ændret.

Dette er en ændring for hele klyngen med en reel slagradius. Når den er landet, ankommer trafik, der før beholdt sin pod-kilde, nu omskrevet til noden, så alt, der var nøglet til de pod-adresser, ser en anden afsender. Ofrene er logfiler, tilladelseslister og lokale firewall-regler, der navngiver pod-adresser, og de fejler lydløst. Annoncer ændringen som en adfærdsændring frem for en rettelse.

I en klynge med flere node-pools skal du kontrollere, at agenten er planlagt på de noder, hvor de berørte pods faktisk kører. En pool uden DaemonSet beholder sine gamle regler, og intet i ConfigMap vil vise det.

Alternativet og dets pris

Den anden mulighed holder pod-adresser intakte og lærer ruten om dem. Pod-CIDR'et går ind i Cloud VPNs trafikvælgere, og den lokale side har brug for en returrute til det, så svar ved, hvor de skal hen. Det bevarer pod-identitet, som nogle sikkerhedsmodeller ønsker, og det udvider både routing- og firewall-omfanget, som den anden side skal acceptere.

Handlen er læsbarhed mod omfang. Oversættelse får den lokale side til at se én adresse pr. node, hvilket er nemt at sætte på en tilladelsesliste og skjuler, hvilken pod der sendte hvad. Ingen oversættelse holder pod-adressen ende-til-ende, hvilket er bedre for tilskrivning og værre for hver enhed på ruten, der skal lære et nyt område. Ingen af mulighederne er en Docker- eller CNI-defekt; begge er routing-beslutninger med en driftsregning. Vælg den, hvis regning dit team kan betale, og skriv ned hvorfor.

Verificer og rul tilbage

Kør den samme optagelse igen. En optagelse på node-niveau, der stadig udskriver pod-adressen efter din redigering, betyder, at reglerne aldrig blev ændret, uanset hvad ConfigMap siger. Kablet er kendsgerningen; alt andet er slutning.

Kontroller derefter den modsatte retning, fordi halvdelen af disse ændringer kun verificeres udad. Bekræft, at svaret når den node eller pod, der sendte anmodningen, og bekræft, at applikationen blev færdig i stedet for blot at modtage en SYN. En optagelse, der viser en anmodning uden svar, er et routing-problem på den anden side, ikke et masquerade-problem på denne.

Tilbagerulning er den forrige ConfigMap, anvendt på samme måde, med samme bekræftelse af, at agenten blev genstartet, og reglerne ændret. Gem kildeadressen før og efter for én kendt anmodning i ændringsregistret, da netop den ene linje beviser, at ændringen gjorde, hvad du sagde. GKE-vejledningen om IP-masquerade-agenten dokumenterer standardværdierne og ConfigMap-felterne. Hvis kildeadressen er uændret efter udrulningen, kører agenten ikke på den node, og ingen mængde YAML-redigering vil rette det.