„Pod“ VPN „Kubernetes“ aplinkoje ar išėjimo tarpinė: kam priklauso tunelis?

Diegiate „Pod“ pavadinimu vpn-gateway, nukreipiate bandymo klientą į jo adresą ir matote, kaip paketai dingsta. Manifeste nieko nėra negerai, o kubelet neturi priekaištų. Priežastis yra struktūrinė, o ne konfigūracinė: „Kubernetes“ kiekvienam „Pod“ suteikia savo tinklo vardų erdvę, todėl pavadinimas, žymė ar bendra API vardų erdvė nieko nekeičia paketų kryptimi. Todėl sprendimas, kaip VPN srautas palieka klasterį, prasideda nuosavybės klausimu, o ne konteinerių atvaizdų klausimu.

Du mechanizmai apima daugumą realių diegimų, ir jie nėra keičiami. Vienas įdeda tunelį į pačios darbo apkrovos tinklo vardų erdvę. Kitas prašo CNI nukreipti pasirinktą srautą per paskirtą tarpinės mazgą. Jie nepavyksta skirtingai, skalėjasi skirtingai ir atsiskaito skirtingoms komandoms, todėl konteinerių klausimas paprastai sukelia ginčus, kurie niekada neišsprendžiami.

„Pod“ riba yra vardų erdvė, o ne šuolio mazgas

„Linux“ tinklo vardų erdvė valdo savo sąsajas, adresus, maršrutus ir ugniasienės taisykles, ir kiekvienas „Pod“ gauna vieną. To „Pod“ konteineriai jai prisijungia, ir būtent todėl pagalbinis konteineris gali perrašyti maršrutus, kurių vėliau laikosi programa. Kaimyninis „Pod“ turi identiškai atrodančią, bet visiškai atskirą steką. Nėra bendros lentelės, kurią galėtų paveldėti tarpinės „Pod“, ir nėra implicitinio srauto perdavimo iš vienos vardų erdvės į kitą.

Todėl tarpinės „Pod“ modelis veikia tik tada, kai kažkas aukščiau tikrai siunčia jam paketus: „Service“, statinis maršrutas mazge arba nukreipimo politika CNI. Vien adresas nieko netraukia.

Ką tunelis kiekvienam „Pod“ duoda ir kiek kainuoja

Tunelis, veikiantis darbo apkrovos vardų erdvėje, suteikia tai apkrovai savo kliento tapatybę, kurios daugelis nuotolinės prieigos paslaugų reikalauja prieš autorizuodamos ar apskaitydamos sesiją. Žalos spindulys taip pat lieka vietinis: sugedęs tunelis išjungia vieną „Deployment“, o ne bendrą kelią, kurį naudoja viskas. Kaip jis veikia, priklauso nuo įgyvendinimo, ir čia žmonės spėja neteisingai.

Sąranka, kuriai reikia tik branduolio būsenos, gali baigtis init konteineryje ir išeiti. Vartotojo erdvės demonas, kuris turi išlikti gyvas visą „Pod“ gyvavimo laiką, reikalauja paleidžiamos iš naujo init konteinerio formos, kuri „Kubernetes 1.29“ buvo pristatyta kaip natūralus šoninis konteineris, ir šis skirtumas kyla iš tunelio įgyvendinimo, o ne iš skonio. Šio modelio kaina yra dubliavimas: kiekviena replika autentifikuojasi, gauna savo tunelio adresą ir užima nuotolinės sesijos vietą, todėl automatinio mastelio įvykis tampa talpos įvykiu kitoje ryšio pusėje. Vieno kredencialo kopijavimas į visas replikas šios kainos nepanaikina, jis panaikina audito pėdsaką. Teisės nusipelno to paties patikrinimo, nes tunelis, norintis NET_ADMIN savo vardų erdvėje, neturi pagrindo paveldėti viso mazgo valdžios iš pavyzdžio su privileged: true.

Kai CNI valdo išėjimą

Jei CNI tai palaiko, išėjimo tarpinė parenka srautą pagal darbo apkrovą ir paskirties diapazoną, tada siunčia jį per pasirinktus mazgus pagal vieną nuspėjamą šaltinio adresą. „Cilium“ versija yra įprasta nuoroda, o jos dokumentacija aiškiai nurodo, kad funkcijai reikia konkrečios „Cilium“ konfigūracijos ir tarpinės mazgų su tinkamomis sąsajomis bei adresais. Ji taip pat mini pradinį laikotarpį po „Pod“ sukūrimo, kai nukreipimas dar netaikomas, ir tai yra dizaino įvestis, o ne išnaša.

Skaitykite šį vėlavimą savo pažado atžvilgiu. Jei taisyklė yra ta, kad joks srautas negali išeiti kitu keliu, naujas „Pod“, siunčiantis spragos metu, jau ją pažeidė, todėl paleidimo seka turi savo atsakymą: sulaikyti programą, kol politika įsigalios, arba priimti langą ir jį dokumentuoti.

Laikykite teiginį siaurą. Išėjimo tarpinė parenka ir išverčia kelią. Ji nepabaigia VPN ir nepaverčia klasterio jūsų nuotolinio tinklo klientu be palaikomo ryšio už jos.

Vertimas tyliai pakeičia tai, ką mato nuotolinė pusė

Kai tarpinė perrašo šaltinį, kiekvieno „Pod“ adresai dingsta, todėl tapatybe pagrįstas leidžiamųjų sąrašas tampa sąrašu, pagrįstu vienu bendru adresu. Tai mainai, o ne defektas: mažiau taisyklių prižiūrėti, grubesnis priskyrimas, kai kažkas elgiasi blogai.

Programos lygmens autentifikavimas ir užklausų registravimas turi nešti tai, ko tinklas nebepraneša. Traktuokite tarpinės talpą ir pakeitimą kaip bendrą infrastruktūrą, nes vieno mazgo perkrovimas dabar nutraukia kiekvieną darbo apkrovą už jo, ir anksti patikrinkite grįžimo kelią: nuotolinis galas turi žinoti, kaip pasiekti išverstą adresą, paprastai per maršrutą ar NAT, kurį turi valdyti žmogus, o ne manifestas. Adresų planavimas taip pat priklauso čia, nes persidengiantys klasterio ir nuotoliniai diapazonai sugriauna abu modelius, o IPv6 priėmimas nepateisina prieštaringo plano.

Nuspręskite pagal nuosavybę, tada išbandykite pažadėtą gedimą

Rinkitės tunelį kiekvienam „Pod“, kai nuotolinė paslauga autentifikuoja atskiras darbo apkrovas, kai ryšio reikia tik keliems „Deployment“, ir kai gedimas turi likti vietinis. Rinkitės tarpinę, kai tinklo komanda jau valdo kelią, kai daug apkrovų dalijasi viena paskirtimi, ir kai stabili šaltinio adresas yra visas pratimo tikslas.

Bet kuriuo atveju patikrinkite parduotą savybę, o ne pastovią būseną. Sukurkite „Pod“, leiskite jam iš karto siųsti ir stebėkite pirmąsias sekundes, jei pažadas buvo, kad niekas nepabėgs iš tunelio. Padidinkite iki penkių replikų ir suskaičiuokite sesijas, apie kurias praneša nuotolinis galas, jei pažadas buvo tapatybė kiekvienai apkrovai. Šie du patikrinimai atskleidžia mechanizmo ribas daug greičiau nei manifesto peržiūra, ir jie pasako, kuriai komandai priklauso kitas incidentas.