Pod-VPN en Kubernetes kontraŭ elireja pordego: kiu posedas la tunelon?

Vi disfaligas Pod nomatan vpn-gateway, direktas testan klienton al ĝia adreso kaj vidas la pakaĵojn malaperi. Nenio en la manifesto malĝustas kaj la kubelet havas nenion por plendi. La kaŭzo estas struktura, ne agorda: Kubernetes donas al ĉiu Pod sian propran retan nomspacon, do nomo, etikedo aŭ komuna API-nomspaco ŝanĝas nenion pri tio, kien la pakaĵoj iras. Decidi, kiel VPN-trafiko forlasas la klusteron, do komenciĝas per demando pri posedo, ne pri ujaj bildoj.

Du mekanismoj kovras la plej multajn realajn disfaldojn, kaj ili ne estas interŝanĝeblaj. Unu metas la tunelon en la propran retan nomspacon de la laborŝarĝo. La alia petas al la CNI gvidi elektitan trafikon tra difinita pordega nodo. Ili malsukcesas malsame, skaliĝas malsame kaj raportas al malsamaj teamoj, kaj tial la uja demando kutime produktas disputojn, kiuj neniam finiĝas.

Poda limo estas nomspaco, ne saltgastiganto

Linuksa reta nomspaco posedas siajn interfacojn, adresojn, itinerojn kaj fajroŝirmilajn regulojn, kaj ĉiu Pod ricevas unu. Ujoj ene de tiu Pod aliĝas al ĝi, kaj ĝuste tial helpa ujo povas reskribi itinerojn, kiujn la aplikaĵo poste sekvas. Najbara Pod havas idente aspektan sed tute apartan stakon. Ne ekzistas komuna tabelo por heredi fare de pordega Pod, kaj ne ekzistas implica transdono de trafiko de unu nomspaco al alia.

Tial ankaŭ la pordega Poda ŝablono funkcias nur kiam io supre efektive sendas pakaĵojn al ĝi: Service, statika itinero sur la nodo aŭ gvida politiko en la CNI. Adreso sola altiras nenion.

Kion tunelo por ĉiu Pod aĉetas, kaj kion ĝi kostas

Tunelo funkcianta en la nomspaco de la laborŝarĝo donas al tiu laborŝarĝo sian propran klientan identecon, kiun multaj malproksimaj alirservoj postulas antaŭ ol rajtigi aŭ kalkuli sesion. Ankaŭ la difekta radiuso restas loka: rompita tunelo forigas unu Deployment anstataŭ la komunan vojon uzatan de ĉio. Kiel ĝi funkcias dependas de la efektivigo, kaj ĉi tie homoj konjektas malĝuste.

Agordo, kiu bezonas nur kernan staton, povas finiĝi en init-ujo kaj eliri. Uzantspaca demono, kiu devas resti viva dum la tuta vivo de la Pod, bezonas la restarteblan init-ujan formon enkondukitan kiel denaska flankujaĵo en Kubernetes 1.29, kaj tiu distingo venas de la tunela efektivigo, ne de gusto. La kosto de ĉi tiu modelo estas duobligo: ĉiu repliko aŭtentikigas, ricevas sian propran tunelan adreson kaj okupas malproksiman sesian ingon, do aŭtoskaliga okazaĵo fariĝas kapacita okazaĵo ĉe la alia flanko de la ligilo. Kopii unu legitimaĵon en ĉiujn replikojn ne forigas tiun koston, ĝi forigas la revizian spuron. Kapabloj meritas la saman ekzamenon, ĉar tunelo, kiu volas NET_ADMIN en sia propra nomspaco, havas neniun kialon heredi la gastigantan aŭtoritaton de ekzemplo kun privileged: true.

Kiam la CNI posedas la eliron

Se la CNI subtenas tion, elireja pordego elektas trafikon laŭ laborŝarĝo kaj celgamo, poste sendas ĝin tra elektitaj nodoj sub unu antaŭvidebla fontadreso. La versio de Cilium estas la kutima referenco, kaj ĝia dokumentaro klare diras, ke la funkcio bezonas apartan Cilium-agordon plus pordegajn nodojn provizitajn per la ĝustaj interfacoj kaj adresoj. Ĝi ankaŭ mencias komencan periodon post la kreado de Pod, kiam gvidado ankoraŭ ne estas devigata, kio estas projekt-enigaĵo, ne piednoto.

Legu tiun prokraston kontraŭ via propra promeso. Se la regulo estas, ke neniu trafiko rajtas eliri per alia vojo, nova Pod, kiu elsendas dum la breĉo, jam rompis ĝin, do la starta sinsekvo bezonas sian propran respondon: tenu la aplikaĵon ĝis la politiko validas, aŭ akceptu la fenestron kaj dokumentu ĝin.

Tenu la aserton mallarĝa. Elireja pordego elektas kaj tradukas vojon. Ĝi ne finigas VPN, kaj ĝi ne igas la klusteron kliento de via malproksima reto sen subtenata konekto malantaŭ ĝi.

Tradukado kaŝe ŝanĝas tion, kion vidas la malproksima flanko

Post kiam la pordego reskribas la fonton, la adresoj por ĉiu Pod malaperas, do permeslisto bazita sur identeco fariĝas permeslisto bazita sur unu komuna adreso. Tio estas interŝanĝo, ne difekto: malpli da reguloj por prizorgi, pli kruda atribuo kiam io miskondutas.

Aŭtentikigo ĉe aplikaĵa nivelo kaj petprotokolado devas porti tion, kion la reto ne plu raportas. Traktu pordegan kapaciton kaj anstataŭigon kiel komunan infrastrukturon, ĉar restartiĝo de unu nodo nun interrompas ĉiun laborŝarĝon malantaŭ ĝi, kaj kontrolu la revenan vojon frue: la malproksima fino devas scii, kiel atingi la tradukitan adreson, kutime per itinero aŭ NAT, kiun persono, ne manifesto, devas posedi. Adresa planado ankaŭ apartenas ĉi tien, ĉar interkovrantaj klusteraj kaj malproksimaj gamoj rompas ambaŭ modelojn kaj la adopto de IPv6 ne senkulpigas kontraŭdiran planon.

Decidu laŭ posedo, poste testu la malsukceson, kiun vi promesis

Elektu la tunelon por ĉiu Pod kiam la malproksima servo aŭtentikigas individuajn laborŝarĝojn, kiam nur kelkaj Deployment bezonas la ligilon, kaj kiam malsukceso devas resti loka. Elektu la pordegon kiam reta teamo jam posedas la vojon, kiam multaj laborŝarĝoj kunhavas unu celon, kaj kiam stabila fontadreso estas la tuta senco de la ekzerco.

Ĉiel ajn, kontrolu la econ, kiun vi vendis, ne la stabilan staton. Kreu Pod, lasu ĝin tuj elsendi kaj observu la unuajn sekundojn se la promeso estis, ke nenio eskapas el la tunelo. Skalu al kvin replikoj kaj nombru la sesiojn, kiujn la malproksima fino raportas, se la promeso estis identeco por ĉiu laborŝarĝo. Tiuj du kontroloj malkaŝas la limojn de la mekanismo multe pli rapide ol revizio de la manifesto, kaj ili diras al vi, kiu teamo posedas la sekvan incidenton.