VPN na Pod v Kubernetesu proti izhodnemu prehodu: komu pripada tunel?
Pod je lasten omrežni imenski prostor, zato je prava izbira, katera plast ima tunel: identiteta za vsako delovno obremenitev ali izhod, ki ga vodi CNI z enim skupnim virom.
Namestite Pod z imenom vpn-gateway, usmerite testnega odjemalca na njegov naslov in vidite, kako paketi izginejo. V manifestu ni nič narobe in kubelet nima pripomb. Razlog je strukturni in ne konfiguracijski: Kubernetes vsakemu Podu dodeli lasten omrežni imenski prostor, zato ime, oznaka ali skupni imenski prostor API ne spremenijo ničesar glede tega, kam gredo paketi. Zato se odločitev, kako promet VPN zapusti gručo, začne z vprašanjem o lastništvu, ne o slikah vsebnikov.
Dva mehanizma pokrivata večino resničnih postavitev in nista zamenljiva. Eden postavi tunel v lastni omrežni imenski prostor delovne obremenitve. Drugi prosi CNI, naj izbrani promet usmeri skozi določeno vozlišče prehoda. Spodletita različno, se skalirata različno in odgovarjata različnim ekipam, zato vprašanje vsebnikov običajno ustvari spore, ki se nikoli ne končajo.
Meja Poda je imenski prostor, ne gostitelj skoka
Omrežni imenski prostor Linuxa ima svoje vmesnike, naslove, poti in pravila požarnega zidu, in vsak Pod dobi enega. Vsebniki v tem Podu se mu pridružijo, zato lahko pomožni vsebnik prepiše poti, ki jim aplikacija nato sledi. Sosednji Pod ima enako videti, a popolnoma ločen sklad. Ni skupne tabele, ki bi jo Pod prehoda lahko podedoval, in ni implicitne predaje prometa iz enega imenskega prostora v drugega.
Zato vzorec Poda prehoda deluje le, ko nekaj višje resnično pošilja pakete vanj: Service, statična pot na vozlišču ali politika usmerjanja v CNI. Sam naslov ne privlači ničesar.
Kaj tunel na Pod prinese in koliko stane
Tunel, ki teče v imenskem prostoru delovne obremenitve, tej obremenitvi da lastno identiteto odjemalca, ki jo mnoge storitve oddaljenega dostopa zahtevajo, preden odobrijo ali obračunajo sejo. Tudi doseg škode ostane lokalen: pokvarjen tunel izloči en Deployment namesto skupne poti, ki jo uporablja vse. Kako teče, je odvisno od izvedbe, in prav tu ljudje ugibajo napačno.
Nastavitev, ki potrebuje samo stanje jedra, se lahko konča v init vsebniku in izstopi. Uporabniški demon, ki mora ostati živ vso življenjsko dobo Poda, potrebuje ponovno zaganljivo obliko init vsebnika, uvedeno kot izvorni stranski vsebnik v Kubernetes 1.29, in ta razlika izhaja iz izvedbe tunela, ne iz okusa. Cena tega modela je podvajanje: vsaka replika se overi, dobi svoj naslov tunela in zasede mesto oddaljene seje, zato dogodek samodejnega skaliranja postane dogodek zmogljivosti na drugi strani povezave. Kopiranje ene poverilnice v vse replike te cene ne odpravi, odpravi revizijsko sled. Dovoljenja si zaslužijo enak pregled, saj tunel, ki hoče NET_ADMIN v svojem imenskem prostoru, nima razloga podedovati oblasti nad celotnim gostiteljem iz primera z privileged: true.
Ko izhod ima CNI
Če CNI to podpira, izhodni prehod izbere promet glede na delovno obremenitev in obseg cilja, nato pa ga pošlje skozi izbrana vozlišča pod enim predvidljivim izvornim naslovom. Različica Cilium je običajen sklic, njena dokumentacija pa jasno navaja, da funkcija zahteva posebno konfiguracijo Cilium in vozlišča prehoda z ustreznimi vmesniki in naslovi. Omenja tudi začetno obdobje po ustvarjanju Poda, ko usmerjanje še ni uveljavljeno, kar je vhod za zasnovo in ne opomba pod črto.
To zamudo berite proti svoji obljubi. Če je pravilo, da noben promet ne sme oditi po drugi poti, ga je nov Pod, ki oddaja v vrzeli, že prekršil, zato zagonsko zaporedje potrebuje svoj odgovor: zadržati aplikacijo, dokler se politika ne uveljavi, ali okno sprejeti in dokumentirati.
Držite trditev ozko. Izhodni prehod izbere in prevede pot. Ne zaključi VPN in gruče ne spremeni v odjemalca vašega oddaljenega omrežja brez podprte povezave za njim.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
Prevod tiho spremeni, kaj vidi oddaljena stran
Ko prehod prepiše izvor, naslovi posameznih Podov izginejo, zato seznam dovoljenih, vezan na identiteto, postane seznam, vezan na en skupni naslov. To je menjava in ne napaka: manj pravil za vzdrževanje, grobje dodeljevanje, ko se kaj obnaša slabo.
Preverjanje pristnosti na ravni aplikacije in beleženje zahtev morata nositi, česar omrežje ne poroča več. Zmogljivost in zamenjavo prehoda obravnavajte kot skupno infrastrukturo, ker ponovni zagon enega vozlišča zdaj prekine vsako delovno obremenitev za njim, in povratno pot preverite zgodaj: oddaljeni konec mora vedeti, kako doseči prevedeni naslov, običajno prek poti ali NAT, ki ga mora imeti človek, ne manifest. Tudi načrtovanje naslovov spada sem, ker prekrivajoči se obsegi gruče in oddaljenega omrežja pokvarijo oba modela in uvedba IPv6 ne opravičuje nasprotujočega si načrta.
Odločite se po lastništvu, nato preizkusite obljubljeno napako
Izberite tunel na Pod, ko oddaljena storitev overi posamezne obremenitve, ko povezavo potrebuje le nekaj Deploymentov in ko mora napaka ostati lokalna. Izberite prehod, ko pot že ima omrežna ekipa, ko si veliko obremenitev deli en cilj in ko je stabilen izvorni naslov ves smisel vaje.
Kakor koli, preverite lastnost, ki ste jo prodali, in ne ustaljenega stanja. Ustvarite Pod, pustite, da takoj oddaja, in opazujte prve sekunde, če je bila obljuba, da iz tunela nič ne uide. Povečajte na pet replik in preštejte seje, ki jih poroča oddaljeni konec, če je bila obljuba identiteta na obremenitev. Ti dve preveritvi razkrijeta meje mehanizma veliko hitreje kot pregled manifesta in povesta, kateri ekipi pripada naslednji incident.