Pod, čvor ili klaster: što VPN sidecar zapravo preusmjerava
Kontejneri u jednom Podu dijele mrežni imenski prostor, pa sidecar koji mijenja rute utječe na aplikaciju, ali ne na druge Podove ni na čvor.
VPN sidecar u Kubernetes Podu izgleda kao VPN na razini hosta s boljim ponašanjem, a sličnost prestaje na granici imenskog prostora. Kontejneri u jednom Podu dijele mrežni imenski prostor, uključujući adresni i portni prostor, pa sidecar koji postavlja rute i politiku doista mijenja kamo idu paketi aplikacije. Za ostale Podove na čvoru ne mijenja ništa i ne dira vlastiti stog čvora, osim ako ga tako konfigurirate. Ispravno razumijevanje te granice određuje i što možete uvesti i što morate testirati. Odsjeci u nastavku prate to od imenskog prostora prema van.
Zajednički imenski prostor, zajedničke posljedice
Dva kontejnera u Podu razgovaraju preko loopbacka i vide iste sučelja, i zato sidecar uzorak uopće funkcionira: aplikacija ne mora znati da tunel postoji, jer je ruta koju razriješi postavljena u imenskom prostoru koji koristi. Isto svojstvo znači da su sidecarove pogreške aplikacijske pogreške. Ruta koja hvata previše, ili DNS promjena koja pokazuje na razrješivač unutar tunela, odmah se primjenjuje na svaki proces u tom Podu. U zajedničkom imenskom prostoru nema usmjeravanja po kontejneru, pa se sidecar ne može ograničiti na jedan proces.
To je mehanizam koji treba imati na umu tijekom pregleda: domet utjecaja je Pod, ne čvor i ne klaster.
Do čega sidecar ne dopire
Ostali Podovi zadržavaju svoje imenske prostore i svoje usmjeravanje, pa radno opterećenje koje treba isti izlaz treba isti sidecar ili, umjesto toga, dizajn na razini čvora. Ni promet čvora nije unutar imenskog prostora Poda, a Podovi s mrežom hosta svjesno u potpunosti odustaju od te izolacije. Ako sidecar pokrenete s mrežom hosta da dosegnete nešto zgodno, proširili ste obuhvat s jednog Poda na cijeli čvor i to biste trebali glasno reći.
Promet prema servisima klastera drugo je često iznenađenje. Široka zadana ruta unutar Poda može uhvatiti zahtjeve namijenjene API poslužitelju ili servisu ClusterIP, a oni zatim padaju na način koji izgleda kao da je tunel pokvaren.
Plan ruta: Pod, servis, čvor i VPN rasponi
Zapišite četiri raspona i provjerite ih na preklapanje prije nego što bilo što uvedete: Pod CIDR, servisni CIDR, adrese čvora i odredišta iza VPN-a. Preklapanje između privatnih raspona VPN-a i vlastitog prostora klastera nije rijetko, a zadana ruta je pogrešno rješenje za to. Plan ruta pripada u isti repozitorij kao manifest, jer sljedeći klaster može dodijeliti posve drukčije Pod i servisne raspone.
DNS je dio plana, a ne odvojena briga. Sidecar koji prepisuje konfiguraciju razrješivača može slomiti otkrivanje servisa unutar klastera dok vanjsko pretraživanje radi besprijekorno.
Pokretanje i kvar eksplicitna su stanja
Pokrenuti sidecar proces nije izlazna politika. Odlučite koji promet smije teći prije nego tunel bude spreman i što se dogodi ako poslije umre, pa tu odluku provedite: proba koja propušta kontejner aplikacije, mrežna politika koja odbija po zadanom, ili oboje. Bez ijednoga od toga aplikacija se pokrene, razriješi i pošalje promet izvan uobičajene putanje čvora dok se tunel još povezuje.
Ta je praznina kratka u zdravom klasteru i trajna u pokvarenom, i to je upravo svojstvo koje napadač ili slučajno curenje podataka preferiraju.
Uparite redoslijed s testom kvara. Ubijte sidecar i potvrdite da aplikacija gubi predviđeni izlaz umjesto da se tiho vraća natrag.
Sposobnosti, politike i testiranje iz kontejnera aplikacije
Dodjela sposobnosti potrebnih za stvaranje sučelja i mijenjanje ruta odluka je o privilegijama, a privilegija primjerena izoliranom Podu nije automatski primjerena na stogu čvora. Rabite mehanizme mrežne i sigurnosne politike koje klaster podržava i ne pretpostavljajte da svaka implementacija CNI-ja ili politike tretira VPN sučelje jednako; razlike se pokazuju upravo u slučajevima kvara do kojih vam je stalo.
Testirajte iz stvarnog kontejnera aplikacije, svježim zahtjevima prema privatnom odredištu, servisu klastera i javnom internetu. Test iz sidecara dokazuje da tunel radi, ne da aplikacija može dosegnuti ono što joj treba.
Dokumentirajte pretpostavke mreže klastera uz VPN konfiguraciju. Premještanje radnog opterećenja u drugi klaster tada je vježba provjere plana ruta, a ne promjena slike koja tiho prestaje raditi.