VPN për Pod në Kubernetes kundrejt portës dalëse: kujt i takon tuneli?

Ju vendosni një Pod të quajtur vpn-gateway, drejtoni një klient prove në adresën e tij dhe shihni paketat duke u zhdukur. Asgjë në manifest nuk është gabim dhe kubelet nuk ka ankesa. Arsyeja është strukturore dhe jo konfiguruese: Kubernetes i jep çdo Pod hapësirën e vet të emrave të rrjetit, prandaj një emër, një etiketë ose një hapësirë e përbashkët emrash API nuk ndryshojnë asgjë se ku shkojnë paketat. Prandaj vendimi se si trafiku VPN del nga klasteri fillon me një pyetje për pronësinë, jo për imazhet e kontejnerëve.

Dy mekanizma mbulojnë shumicën e vendosjeve reale, dhe ata nuk janë të këmbyeshëm. Njëri e vendos tunelin brenda hapësirës së emrave të rrjetit të vetë ngarkesës së punës. Tjetri i kërkon CNI-së të drejtojë trafikun e zgjedhur përmes një nyje porte të caktuar. Ata dështojnë ndryshe, shkallëzohen ndryshe dhe i përgjigjen ekipeve të ndryshme, prandaj pyetja e kontejnerëve zakonisht prodhon debate që nuk mbyllen kurrë.

Kufiri i Pod është një hapësirë emrash, jo një host kërcimi

Hapësira e emrave të rrjetit të Linux-it zotëron ndërfaqet, adresat, rrugët dhe rregullat e murit të zjarrit të vet, dhe çdo Pod merr një. Kontejnerët brenda atij Pod i bashkohen asaj, dhe pikërisht për këtë një kontejner ndihmës mund të rishkruajë rrugë që aplikacioni i ndjek më pas. Një Pod fqinj ka një stivë me pamje identike, por plotësisht të veçantë. Nuk ka tabelë të përbashkët që një Pod portë të mund të trashëgojë, dhe nuk ka kalim të nënkuptuar të trafikut nga një hapësirë emrash në tjetrën.

Prandaj modeli i Pod-it portë funksionon vetëm kur diçka më lart i dërgon vërtet paketa: një Service, një rrugë statike në nyje ose një politikë drejtimi në CNI. Një adresë e vetme nuk tërheq asgjë.

Çfarë blen një tunel për çdo Pod dhe sa kushton

Një tunel që punon në hapësirën e emrave të ngarkesës së punës i jep asaj ngarkese identitetin e vet të klientit, të cilin shumë shërbime të aksesit në distancë e kërkojnë përpara se të autorizojnë ose të llogarisin një sesion. Rrezja e dëmit gjithashtu mbetet lokale: një tunel i prishur nxjerr jashtë loje një Deployment në vend të rrugës së përbashkët që përdor gjithçka. Si punon varet nga zbatimi, dhe këtu njerëzit hamendësojnë gabim.

Një konfigurim që ka nevojë vetëm për gjendjen e kernelit mund të përfundojë në një kontejner init dhe të dalë. Një demon në hapësirën e përdoruesit që duhet të mbetet i gjallë gjatë gjithë jetës së Pod ka nevojë për formën e kontejnerit init të rindezshëm të prezantuar si sidecar vendës në Kubernetes 1.29, dhe ky dallim vjen nga zbatimi i tunelit, jo nga shija. Kostoja e këtij modeli është dublimi: çdo replikë vërteton identitetin, merr adresën e vet të tunelit dhe zë një vend sesioni në distancë, kështu që një ngjarje autoshkallëzimi bëhet ngjarje kapaciteti në anën tjetër të lidhjes. Kopjimi i një kredenciali të vetëm në të gjitha replikat nuk e heq atë kosto, heq gjurmën e auditimit. Edhe aftësitë meritojnë të njëjtin shqyrtim, sepse një tunel që do NET_ADMIN në hapësirën e vet të emrave nuk ka arsye të trashëgojë autoritetin mbi të gjithë hostin nga një shembull me privileged: true.

Kur CNI zotëron daljen

Nëse CNI e mbështet, një portë dalëse zgjedh trafikun sipas ngarkesës së punës dhe intervalit të destinacionit, pastaj e dërgon përmes nyjeve të zgjedhura nën një adresë burimi të parashikueshme. Versioni i Cilium është referenca e zakonshme, dhe dokumentacioni i tij thotë qartë se funksioni kërkon një konfigurim specifik të Cilium plus nyje porte të pajisura me ndërfaqet dhe adresat e duhura. Ai vëren gjithashtu një periudhë fillestare pas krijimit të Pod kur drejtimi nuk zbatohet ende, dhe ky është një input projektimi, jo një fusnotë.

Lexojeni atë vonesë kundrejt premtimit tuaj. Nëse rregulli është që asnjë trafik nuk mund të dalë nga një rrugë tjetër, një Pod i ri që transmeton gjatë boshllëkut tashmë e ka shkelur, prandaj sekuenca e nisjes ka nevojë për përgjigjen e vet: mbajeni aplikacionin derisa politika të zbatohet, ose pranojeni dritaren dhe dokumentojeni.

Mbajeni pohimin të ngushtë. Një portë dalëse zgjedh dhe përkthen një rrugë. Ajo nuk përfundon një VPN, dhe nuk e kthen klasterin në klient të rrjetit tuaj në distancë pa një lidhje të mbështetur pas saj.

Përkthimi ndryshon në heshtje atë që sheh ana e largët

Sapo porta rishkruan burimin, adresat për çdo Pod zhduken, prandaj një listë lejimesh e bazuar në identitet bëhet një listë e bazuar në një adresë të përbashkët. Është një shkëmbim dhe jo një defekt: më pak rregulla për t’u mirëmbajtur, atribuim më i trashë kur diçka sillet keq.

Vërtetimi në nivel aplikacioni dhe regjistrimi i kërkesave duhet të mbajnë atë që rrjeti nuk raporton më. Trajtojeni kapacitetin dhe zëvendësimin e portës si infrastrukturë të përbashkët, sepse rindezja e një nyjeje të vetme tani ndërpret çdo ngarkesë pune pas saj, dhe kontrolloni herët rrugën e kthimit: ana e largët duhet të dijë si të arrijë adresën e përkthyer, zakonisht përmes një rruge ose NAT-i që duhet ta zotërojë një njeri, jo një manifest. Edhe planifikimi i adresave hyn këtu, sepse intervalet e mbivendosura të klasterit dhe të largëta prishin secilin model dhe adoptimi i IPv6 nuk justifikon një plan kundërshtues.

Vendosni sipas pronësisë, pastaj provoni dështimin që premtuat

Zgjidhni tunelin për çdo Pod kur shërbimi i largët vërteton ngarkesa pune individuale, kur lidhja u duhet vetëm disa Deployment-eve dhe kur një dështim duhet të mbetet lokal. Zgjidhni portën kur një ekip rrjeti e zotëron tashmë rrugën, kur shumë ngarkesa punësh ndajnë një destinacion dhe kur një adresë burimi e qëndrueshme është i gjithë qëllimi i ushtrimit.

Sido që të jetë, verifikoni vetinë që shisni dhe jo gjendjen e qëndrueshme. Krijoni një Pod, lëreni të transmetojë menjëherë dhe vëzhgoni sekondat e para nëse premtimi ishte që asgjë nuk shpëton nga tuneli. Shkallëzojeni në pesë replika dhe numëroni sesionet që raporton ana e largët nëse premtimi ishte identiteti për çdo ngarkesë pune. Këto dy kontrolle i nxjerrin në pah kufijtë e mekanizmit shumë më shpejt se një rishikim i manifestit, dhe ju thonë cilit ekip i takon incidenti i radhës.