VPN u Podu na Kubernetesu nasuprot izlaznom pristupu: kome pripada tunel?

Postavljate Pod imena vpn-gateway, usmjeravate testnog klijenta na njegovu adresu i gledate kako paketi nestaju. Ništa u manifestu nije pogrešno i kubelet nema šta zamjeriti. Razlog je strukturni, a ne konfiguracijski: Kubernetes svakom Podu daje vlastiti mrežni prostor imena, pa ime, oznaka ili zajednički API prostor imena ne mijenjaju ništa u tome kuda paketi idu. Zato odluka o tome kako VPN promet napušta klaster počinje pitanjem vlasništva, a ne pitanjem slika kontejnera.

Dva mehanizma pokrivaju većinu stvarnih implementacija i nisu zamjenjivi. Jedan stavlja tunel unutar vlastitog mrežnog prostora imena radnog opterećenja. Drugi traži od CNI-ja da usmjeri odabrani promet kroz određeni čvor pristupa. Oni ne uspijevaju na različite načine, skaliraju se različito i odgovaraju različitim timovima, zbog čega pitanje kontejnera obično stvara rasprave koje se nikada ne smire.

Granica Poda je prostor imena, a ne skočni host

Linux mrežni prostor imena posjeduje svoja sučelja, adrese, rute i pravila vatrozida, a svaki Pod dobiva jedan. Kontejneri unutar tog Poda pridružuju mu se i upravo zato pomoćni kontejner može prepisati rute koje aplikacija zatim slijedi. Susjedni Pod ima identično izgledajući, ali potpuno odvojen stog. Nema zajedničke tablice koju bi Pod pristupa mogao naslijediti, ni implicitnog prenošenja prometa iz jednog prostora imena u drugi.

Zato obrazac Poda pristupa radi tek kad nešto uzvodno doista šalje pakete prema njemu: Service, statička ruta na čvoru ili politika usmjeravanja u CNI-ju. Sama adresa ne privlači ništa.

Što donosi tunel po Podu i koliko košta

Tunel koji radi u prostoru imena radnog opterećenja daje tom opterećenju vlastiti identitet klijenta, što mnoge usluge daljinskog pristupa traže prije nego što odobre ili obračunaju sesiju. Radijus štete također ostaje lokalni: pokvaren tunel izbaci jedan Deployment umjesto zajedničke staze koju koristi sve. Kako radi ovisi o implementaciji, i upravo tu ljudi pogrešno nagađaju.

Postavljanje kojem treba samo stanje jezgre može završiti u init kontejneru i izaći. Korisnički demon koji mora ostati živ cijeli životni vijek Poda treba restartabilni oblik init kontejnera uveden kao izvorni bočni kontejner u Kubernetesu 1.29, a ta razlika dolazi iz implementacije tunela, a ne iz ukusa. Cijena ovog modela je dupliciranje: svaka replika se autentificira, dobiva vlastitu adresu tunela i zauzima mjesto daljinske sesije, pa događaj automatskog skaliranja postaje događaj kapaciteta na drugoj strani veze. Kopiranje jednih vjerodajnica u sve replike ne uklanja tu cijenu, ono uklanja revizijski trag. Ovlasti zaslužuju istu pažnju, jer tunel koji želi NET_ADMIN u vlastitom prostoru imena nema razloga naslijediti ovlasti nad cijelim hostom iz primjera s privileged: true.

Kada CNI posjeduje izlaz

Ako to CNI podržava, izlazni pristup odabire promet prema radnom opterećenju i rasponu odredišta, a zatim ga šalje kroz odabrane čvorove pod jednom predvidivom izvornom adresom. Ciliumova verzija uobičajeni je referentni primjer, a njegova dokumentacija jasno kaže da značajka traži posebnu Cilium konfiguraciju plus čvorove pristupa opremljene pravim sučeljima i adresama. Također navodi početno razdoblje nakon stvaranja Poda kada usmjeravanje još nije primijenjeno, što je ulazni podatak za dizajn, a ne fusnota.

Pročitajte to kašnjenje nasuprot vlastitom obećanju. Ako je pravilo da nikakav promet ne smije izaći drugim putem, novi Pod koji prenosi tijekom praznine već ga je prekršio, pa slijed pokretanja treba vlastiti odgovor: zadržite aplikaciju dok se politika ne primijeni ili prihvatite prozor i dokumentirajte ga.

Držite tvrdnju uskom. Izlazni pristup bira i prevodi put. On ne prekida VPN i ne pretvara klaster u klijenta vaše daljinske mreže bez podržane veze iza njega.

Prevođenje tiho mijenja ono što daljinska strana vidi

Nakon što pristup prepiše izvor, adrese pojedinih Podova nestaju, pa popis dopuštenih koji se oslanja na identitet postaje popis koji se oslanja na jednu zajedničku adresu. To je razmjena, a ne nedostatak: manje pravila za održavanje, grublje pripisivanje kad nešto pogriješi.

Autentifikacija na razini aplikacije i zapisivanje zahtjeva moraju nositi ono što mreža više ne izvješćuje. Tretirajte kapacitet i zamjenu pristupa kao zajedničku infrastrukturu, jer restart jednog čvora sada prekida svako radno opterećenje iza njega, i provjerite povratni put rano: daljinska strana mora znati kako doći do prevedene adrese, obično preko rute ili NAT-a koji čovjek, a ne manifest, mora posjedovati. Planiranje adresa također spada ovamo, jer preklapajući rasponi klastera i daljinske mreže lome oba modela i usvajanje IPv6 ne opravdava sukobljeni plan.

Odlučite po vlasništvu, zatim testirajte kvar koji ste obećali

Odaberite tunel po Podu kada daljinska usluga autentificira pojedinačna radna opterećenja, kada veza treba samo nekoliko Deploymenta i kada kvar treba ostati lokalni. Odaberite pristup kada mrežni tim već posjeduje put, kada mnoga radna opterećenja dijele jedno odredište i kada je stabilna izvorna adresa cijela svrha vježbe.

U svakom slučaju provjerite svojstvo koje ste prodali, a ne stabilno stanje. Stvorite Pod, pustite ga da odmah prenosi i promatrajte prve sekunde ako je obećanje bilo da ništa ne izmiče iz tunela. Skalirajte na pet replika i prebrojite sesije koje daljinska strana prijavljuje ako je obećanje bio identitet po radnom opterećenju. Te dvije provjere otkrivaju granice mehanizma mnogo brže od pregleda manifesta i govore vam koji tim posjeduje sljedeći incident.