Kubernetes-Pod-VPN teenoor uitgangspoort: wie besit die tonnel?

Jy ontplooi ’n Pod met die naam vpn-gateway, wys ’n toetskliënt na sy adres en sien hoe die pakkette verdwyn. Niks in die manifest is verkeerd nie en die kubelet het niks om oor te kla nie. Die rede is struktureel eerder as konfigurasioneel: Kubernetes gee elke Pod sy eie netwerknaamruimte, so ’n naam, ’n etiket of ’n gedeelde API-naamruimte verander niks aan waarheen pakkette gaan nie. Om te besluit hoe VPN-verkeer die cluster verlaat, begin dus met ’n vraag oor eienaarskap, nie oor houerbeelde nie.

Twee meganismes dek die meeste werklike ontplooiings, en hulle is nie uitruilbaar nie. Die een plaas die tonnel binne die werklading se eie netwerknaamruimte. Die ander vra die CNI om gekose verkeer deur ’n aangewese poortnode te stuur. Hulle misluk verskillend, skaal verskillend en rapporteer aan verskillende spanne, en daarom lewer die houervraag gewoonlik argumente wat nooit besleg word nie.

’n Pod-grens is ’n naamruimte, nie ’n spronggasheer nie

’n Linux-netwerknaamruimte besit sy koppelvlakke, adresse, roetes en vuurmuurreëls, en elke Pod kry een. Houers binne daardie Pod sluit daarby aan, en dit is presies waarom ’n hulphouer roetes kan herskryf wat die toepassing dan volg. ’n Naburige Pod het ’n identies lykende maar heeltemal aparte stapel. Daar is geen gedeelde tabel vir ’n poort-Pod om te erf nie, en geen implisiete oorhandiging van verkeer van een naamruimte na ’n ander nie.

Dit is ook waarom die poort-Pod-patroon eers werk wanneer iets stroomopwaarts werklik pakkette daarheen stuur: ’n Service, ’n statiese roete op die node of stuurbeleid in die CNI. ’n Adres alleen lok niks.

Wat ’n tonnel per Pod koop, en wat dit kos

’n Tonnel wat in die werklading se naamruimte loop, gee daardie werklading sy eie kliëntidentiteit, wat baie afstandtoegangdienste vereis voordat hulle ’n sessie magtig of verantwoord. Die skadegebied bly ook plaaslik: ’n stukkende tonnel skakel een Deployment uit in plaas van die gedeelde pad wat alles gebruik. Hoe dit loop, hang van die implementering af, en dit is waar mense verkeerd raai.

Opstelling wat net kerneltoestand nodig het, kan in ’n inithouer klaarmaak en uitgaan. ’n Gebruikerspasie-daemon wat vir die Pod se leeftyd aan die lewe moet bly, het die herbeginbare inithouervorm nodig wat as ’n inheemse sykar in Kubernetes 1.29 bekend gestel is, en daardie onderskeid kom uit die tonnelimplementering eerder as uit smaak. Die koste van hierdie model is duplisering: elke replika verifieer, kry sy eie tonneladres en verbruik ’n afstand-sessieslot, so ’n outoskaleringsgebeurtenis word ’n kapasiteitsgebeurtenis aan die ander kant van die skakel. Om een geloofsbrief na alle replika’s te kopieer verwyder nie daardie koste nie, dit verwyder die ouditspoor. Vermoëns verdien dieselfde ondersoek, want ’n tonnel wat NET_ADMIN in sy eie naamruimte wil hê, het geen rede om die gasheervyde gesag van ’n privileged: true-voorbeeld te erf nie.

Wanneer die CNI eerder uitgang besit

As die CNI dit ondersteun, kies ’n uitgangspoort verkeer op grond van werklading en bestemmingsreeks en stuur dit dan deur gekose nodes onder een voorspelbare bronadres. Cilium se weergawe is die algemene verwysing, en sy dokumentasie is duidelik dat die funksie spesifieke Cilium-konfigurasie plus poortnodes vereis wat met die regte koppelvlakke en adresse voorsien is. Dit noem ook ’n aanvanklike tydperk ná Pod-skepping wanneer sturing nog nie toegepas word nie, wat ’n ontwerpinset eerder as ’n voetnoot is.

Lees daardie vertraging teen jou eie belofte. As die reël is dat geen verkeer langs ’n ander pad mag weggaan nie, het ’n nuwe Pod wat tydens die gaping uitsaai dit reeds gebreek, so die opstartvolgorde het sy eie antwoord nodig: hou die toepassing terug totdat beleid geld, of aanvaar die venster en dokumenteer dit.

Hou die bewering ook smal. ’n Uitgangspoort kies en vertaal ’n pad. Dit beëindig nie ’n VPN nie, en dit verander nie die cluster in ’n kliënt van jou afstandnetwerk sonder ’n ondersteunde verbinding daarachter nie.

Vertaling verander stilweg wat die afstandkant sien

Sodra die poort die bron herskryf, is die adresse per Pod weg, so ’n toelaatlys wat op identiteit geskoei is, word ’n toelaatlys wat op een gedeelde adres geskoei is. Dit is ’n ruil eerder as ’n gebrek: minder reëls om te onderhou, growwer toeskrywing wanneer iets misgaan.

Toepassingvlak-verifikasie en versoeklogboeke moet dra wat die netwerk nie meer rapporteer nie. Behandel poortkapasiteit en -vervanging as gedeelde infrastruktuur, want ’n enkele node-herbegin onderbreek nou elke werklading daarachter, en kontroleer die terugpad vroeg: die afstandkant moet weet hoe om die vertaalde adres te bereik, gewoonlik deur ’n roete of NAT wat ’n mens, nie ’n manifest nie, moet besit. Adresbeplanning hoort ook hier, want oorvleuelende cluster- en afstandsreekse breek enige model en die aanvaarding van IPv6 verskoon nie ’n botsende plan nie.

Besluit volgens eienaarskap, en toets dan die faling wat jy belowe het

Kies die tonnel per Pod wanneer die afstanddiens individuele werkladings verifieer, wanneer net ’n paar Deployment’s die skakel nodig het, en wanneer ’n faling plaaslik moet bly. Kies die poort wanneer ’n netwerkspan reeds die pad besit, wanneer baie werkladings een bestemming deel, en wanneer ’n stabiele bronadres die hele punt van die oefening is.

Hoe dan ook, verifieer die eienskap wat jy verkoop het eerder as die bestendige toestand. Skep ’n Pod, laat dit dadelik uitsaai en kyk na die eerste sekondes as die belofte was dat niks uit die tonnel ontsnap nie. Skaal na vyf replika’s en tel die sessies wat die afstandkant rapporteer as die belofte identiteit per werklading was. Daardie twee kontroles openbaar die grense van die meganisme baie vinniger as ’n hersiening van die manifest, en hulle sê vir jou watter span die volgende voorval besit.