Waarom GKE-pods nie plaaslike gashere oor VPN kan bereik nie

Ping werk vanaf die node en misluk vanaf die pod, en niks kom plaaslik aan nie. Die tonnel en die roete is in orde; die bronadres op die draad is nie. Wat tussen dié twee gevalle verskil, is wat die pakket voorgee om te wees wanneer dit die cluster verlaat, en GKE het 'n mening daaroor. Die meganisme is 'n masquerade-uitsonderingslys, en om dit te lees neem een opdrag.

Lees die effektiewe lys voordat jy iets verander

GKE lewer 'n agent wat per bestemmingsreeks besluit of pod-verkeer op pad uit na die node-adres herskryf word. Sy gelewerde konfigurasie noem die drie RFC1918-blokke, 10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16, as bestemmings wat vrygestel is. Enigiets wat jy vanaf 'n pod na 'n 10.x-gasheer plaaslik stuur, verlaat dus die node met die pod se eie adres steeds aangeheg. Die node se eie verkeer word nie herskryf nie, en dit is presies waarom sy ping werk.

Lees die bedoelde konfigurasie en die geïnstalleerde reëls, want hulle kan verskil. kubectl -n kube-system get configmap ip-masq-agent -o yaml wys wat aan die agent gesê is, en kubectl -n kube-system get pods -l k8s-app=ip-masq-agent wys of enigiets loop om dit toe te pas. Op 'n node wys iptables-save | grep -i masq die reëls wat werklik in die kern bestaan. Wanneer die ConfigMap een ding sê en die reëls 'n ander, is die agent die verdagte eerder as die netwerk.

Bevestig die bronadres met 'n opname

Maak 'n opname voordat jy 'n lys verander. 'n Filter op die een bestemming hou die uitset leesbaar: tcpdump -ni any host 10.20.30.40.

Vergelyk dit met wat die oorkant rapporteer. 'n Opname plaaslik wat die pod-adres wys en geen antwoord nie, maak die sirkel toe: die uitsonderingslys verduidelik die asimmetrie sonder enige tonnelfout. Twee waarnemings van een bronadres is genoeg om op te hou raai oor die CNI.

Vernou die uitsondering tot die pod-CIDR

Die ondersteunde herstelling vernou die vrystelling eerder as om dit te verwyder: hou die pod-CIDR vrygestel en laat die res van die 10.x-ruimte val. Daardie lys woon in die agent se ConfigMap onder nonMasqueradeCIDRs, en om dit te verander is 'n wysiging gevolg deur 'n rollout. Vervang die wye inskrywing met die cluster se werklike pod-reeks, hou die ander private blokke as in-cluster-verkeer dit nog nodig het, en laat resyncInterval alleen tensy jy 'n rede het. Pas dit toe, bevestig dat die agent-pods herbegin het, en bevestig dat die kernreëls verander het.

Dit is 'n clusterwye verandering met 'n werklike impakgebied. Nadat dit land, kom verkeer wat vroeër sy pod-bron behou het, nou herskryf by die node aan, so enigiets wat op daardie pod-adresse gesleutel het, sien 'n ander sender. Die slagoffers is logs, toelatingslyste en plaaslike firewallreëls wat pod-adresse noem, en hulle misluk stilweg. Kondig die verandering as 'n gedragsverandering aan eerder as 'n regstelling.

Op 'n cluster met verskeie node-poelle, kyk of die agent geskeduleer is op die nodes waar die geaffekteerde pods werklik loop. 'n Poel sonder die DaemonSet behou sy ou reëls, en niks in die ConfigMap sal dit wys nie.

Die alternatief en sy koste

Die ander opsie hou pod-adresse ongeskonde en leer die pad daarvan. Die pod-CIDR gaan in die Cloud VPN-verkeerskeurders, en die plaaslike kant het 'n terugroete daarvoor nodig sodat antwoorde weet waarheen om te gaan. Dit bewaar pod-identiteit, wat sommige sekuriteitsmodelle wil hê, en dit verbreed beide die roetering en die firewall-omvang wat die oorkant moet aanvaar.

Die ruil is leesbaarheid teenoor omvang. Vertaling laat die plaaslike kant een adres per node sien, wat maklik is om op 'n toelatingslys te sit en wegsteek watter pod wat gestuur het. Geen vertaling hou die pod-adres end-tot-end, wat beter is vir toeskrywing en slegter vir elke toestel in die pad wat 'n nuwe reeks moet leer. Nie een opsie is 'n Docker- of CNI-defek nie; beide is roeteringsbesluite met 'n operasionele rekening. Kies die een wie se rekening jou span kan betaal, en skryf neer waarom.

Verifieer en rol terug

Hardloop dieselfde opname weer. 'n Opname op node-vlak wat steeds die pod-adres druk ná jou wysiging, beteken die reëls het nooit verander nie, wat die ConfigMap ook al sê. Die draad is die feit; alles anders is afleiding.

Kyk dan na die omgekeerde rigting, want die helfte van hierdie veranderinge word net uitwaarts geverifieer. Bevestig dat die antwoord die node of pod bereik wat die versoek gestuur het, en bevestig dat die toepassing klaargemaak het eerder as om net 'n SYN te ontvang. 'n Opname wat 'n versoek sonder antwoord wys, is 'n roeteringsprobleem aan die oorkant, nie 'n masquerade-probleem aan hierdie kant nie.

Terugrol is die vorige ConfigMap, op dieselfde manier toegepas, met dieselfde bevestiging dat die agent herbegin het en die reëls verander het. Hou die bronadres voor en ná vir een bekende versoek in die veranderingsrekord, want daardie enkele reël is wat bewys die verandering het gedoen wat jy gesê het. Die GKE-gids vir die IP-masquerade-agent dokumenteer die verstekke en die ConfigMap-velde. As die bronadres ná die rollout onveranderd is, loop die agent nie op daardie node nie en geen hoeveelheid YAML-wysiging sal dit regmaak nie.