Pod, mazgas ar klasteris: ką VPN sidecar iš tikrųjų peradresuoja

VPN sidecar Kubernetes Pod aplinkoje atrodo kaip VPN mazgo lygmeniu, tik su geresnėmis manieromis, ir panašumas baigiasi vardų erdvės riboje. Vieno Pod konteineriai dalijasi tinklo vardų erdve, įskaitant adresų ir prievadų erdvę, todėl maršrutus ir politiką diegiantis sidecar tikrai keičia, kur keliauja programos paketai. Kitiems Pod mazge jis nieko nekeičia ir neliečia paties mazgo kamino, nebent taip sukonfigūruosite. Teisingas šios ribos supratimas lemia ir tai, ką galite diegti, ir tai, ką turite testuoti. Toliau esantys skyriai tai seka nuo vardų erdvės į išorę.

Bendra vardų erdvė, bendros pasekmės

Du konteineriai Pod aplinkoje kalba per loopback ir mato tuos pačius sąsajas, ir būtent todėl sidecar šablonas apskritai veikia: programai nereikia žinoti, kad egzistuoja tunelis, nes maršrutas, kurį ji išsprendžia, buvo įdiegtas vardų erdvėje, kurią ji naudoja. Ta pati savybė reiškia, kad sidecar klaidos yra programos klaidos. Maršrutas, kuris pagauna per daug, arba DNS pakeitimas, nukreipiantis į sprendėją tunelio viduje, iš karto taikomas kiekvienam to Pod procesui. Bendroje vardų erdvėje nėra maršrutizavimo pagal konteinerį, todėl sidecar negalima apriboti vienu procesu.

Tai mechanizmas, kurį verta turėti omenyje peržiūros metu: poveikio spindulys yra Pod, o ne mazgas ir ne klasteris.

Kur sidecar nepasiekia

Kiti Pod išlaiko savo vardų erdves ir savo maršrutizavimą, todėl darbo krūviui, kuriam reikia to paties išėjimo, reikia to paties sidecar arba vietoj to mazgo lygmens dizaino. Mazgo srautas taip pat yra už Pod vardų erdvės, o Pod su mazgo tinklu sąmoningai visiškai atsisako šios izoliacijos. Jei sidecar paleidžiate su mazgo tinklu, kad pasiektumėte ką nors patogaus, išplėtėte apimtį nuo vieno Pod iki viso mazgo ir turėtumėte tai garsiai pasakyti.

Srautas į klasterio paslaugas yra dar vienas dažnas netikėtumas. Platus numatytasis maršrutas Pod viduje gali pagauti užklausas, skirtas API serveriui ar ClusterIP paslaugai, ir jos tada žlunga taip, lyg tunelis būtų sugedęs.

Maršrutų planas: Pod, paslaugos, mazgo ir VPN diapazonai

Užrašykite keturis diapazonus ir prieš ką nors diegdami patikrinkite, ar jie nesikerta: Pod CIDR, paslaugos CIDR, mazgo adresai ir paskirties vietos už VPN. VPN privačių diapazonų ir paties klasterio erdvės sutapimas nėra retas, o numatytasis maršrutas tam yra neteisingas sprendimas. Maršrutų planas priklauso tam pačiam saugyklai kaip ir manifestas, nes kitas klasteris gali skirti visiškai kitus Pod ir paslaugų diapazonus.

DNS yra plano dalis, o ne atskiras rūpestis. Sidecar, kuris perrašo sprendėjo konfigūraciją, gali sugriauti paslaugų aptikimą klasterio viduje, tuo tarpu išorinės užklausos veikia nepriekaištingai.

Paleidimas ir gedimas yra aiškios būsenos

Veikiantis sidecar procesas nėra išėjimo politika. Nuspręskite, koks srautas gali tekėti prieš tunelio pasirengimą, ir kas nutiks, jei jis vėliau mirs, tada įgyvendinkite tą sprendimą: zondas, kuris valdo programos konteinerį, tinklo politika, kuri pagal numatytuosius nustatymus atmeta, arba abu. Be vieno iš jų programa paleidžiama, išsprendžia vardus ir siunčia srautą įprastu mazgo keliu, kol tunelis dar jungiasi.

Ši spraga sveikame klasteryje trumpa, o sugedusiame – nuolatinė, ir būtent šią savybę mėgsta užpuolikas ar atsitiktinis duomenų nutekėjimas.

Suderinkite tvarką su gedimo testu. Nužudykite sidecar ir patvirtinkite, kad programa praranda numatytą išėjimą, o ne tyliai atsitraukia.

Galimybės, politikos ir testavimas iš programos konteinerio

Sąsajų kūrimui ir maršrutų keitimui reikalingų galimybių suteikimas yra privilegijų sprendimas, o izoliuotam Pod tinkama privilegija nebūtinai tinka mazgo kamine. Naudokite klasterio palaikomus tinklo ir saugumo politikos mechanizmus ir nedarykite prielaidos, kad kiekviena CNI ar politikos implementacija VPN sąsają traktuoja vienodai; skirtumai pasirodo būtent tuose gedimų atvejuose, kurie jums svarbūs.

Testuokite iš tikro programos konteinerio, su naujomis užklausomis į privačią paskirties vietą, klasterio paslaugą ir viešąjį internetą. Testas iš sidecar įrodo, kad tunelis veikia, o ne kad programa pasiekia tai, ko jai reikia.

Dokumentuokite klasterio tinklo prielaidas šalia VPN konfigūracijos. Tada darbo krūvio perkėlimas į kitą klasterį yra maršrutų plano tikrinimo pratimas, o ne atvaizdo pakeitimas, kuris tyliai nustoja veikti.