Pod, mezgls vai klasteris: ko VPN sidecar patiešām pārvirza

VPN sidecar Kubernetes Pod izskatās kā VPN resursdatora līmenī ar labākām manierēm, un līdzība beidzas nosaukumtelpas robežā. Konteinere vienā Pod dala tīkla nosaukumtelpu, tostarp adrešu un portu telpu, tāpēc sidecar, kas instalē maršrutus un politiku, patiešām maina, kurp dodas lietojumprogrammas paketes. Citiem Pod mezglā tas neko nemaina un neaizskar paša mezgla steku, ja vien jūs to tā nekonfigurējat. Šīs robežas pareiza izpratne nosaka gan to, ko varat izvietot, gan to, kas jums jāpārbauda. Turpmākās sadaļas to izseko no nosaukumtelpas uz āru.

Kopīga nosaukumtelpa, kopīgas sekas

Divi konteinere vienā Pod sarunājas pa loopback un redz tos pašus interfeisus, un tieši tāpēc sidecar modelis vispār darbojas: lietojumprogrammai nav jāzina, ka pastāv tunelis, jo maršruts, ko tā atrisina, tika instalēts nosaukumtelpā, kuru tā izmanto. Tā pati īpašība nozīmē, ka sidecar kļūdas ir lietojumprogrammas kļūdas. Maršruts, kas pārtver pārāk daudz, vai DNS izmaiņas, kas norāda uz atrisinātāju tuneļa iekšienē, nekavējoties attiecas uz katru procesu šajā Pod. Kopīgā nosaukumtelpā nav maršrutēšanas pa konteineriem, tāpēc sidecar nevar ierobežot ar vienu procesu.

Šis ir mehānisms, kas jāpatur prātā pārskatīšanas laikā: ietekmes rādiuss ir Pod, nevis mezgls un nevis klasteris.

Kur sidecar nenokļūst

Citi Pod saglabā savas nosaukumtelpas un savu maršrutēšanu, tāpēc darba slodzei, kurai vajadzīga tā pati izeja, vajadzīgs tas pats sidecar vai tā vietā mezgla līmeņa dizains. Arī mezgla trafiks ir ārpus Pod nosaukumtelpas, un Pod ar resursdatora tīklu apzināti pilnībā atsakās no šīs izolācijas. Ja palaižat sidecar ar resursdatora tīklu, lai sasniegtu kaut ko ērtu, esat paplašinājis apjomu no viena Pod uz visu mezglu, un tas jāsaka skaļi.

Trafiks uz klastera pakalpojumiem ir otrs biežais pārsteigums. Plašs noklusējuma maršruts Pod iekšienē var pārtvert pieprasījumus, kas domāti API serverim vai ClusterIP pakalpojumam, un tie pēc tam neizdodas tā, it kā tunelis būtu salūzis.

Maršrutu plāns: Pod, pakalpojumu, mezgla un VPN diapazoni

Pierakstiet četrus diapazonus un pirms kaut kā izvietošanas pārbaudiet tos uz pārklāšanos: Pod CIDR, pakalpojumu CIDR, mezgla adreses un galamērķi aiz VPN. VPN privāto diapazonu un paša klastera telpas pārklāšanās nav reta, un noklusējuma maršruts tam ir nepareizais risinājums. Maršrutu plāns pieder tai pašai krātuvei kā manifests, jo nākamais klasteris var piešķirt pavisam citus Pod un pakalpojumu diapazonus.

DNS ir plāna daļa, nevis atsevišķas rūpes. Sidecar, kas pārraksta atrisinātāja konfigurāciju, var salauzt pakalpojumu atklāšanu klasterī, kamēr ārējie vaicājumi darbojas nevainojami.

Palaišana un kļūme ir skaidri stāvokļi

Darbojošs sidecar process nav izejas politika. Izlemiet, kāds trafiks drīkst plūst pirms tuneļa gatavības, un kas notiks, ja tas pēc tam nomirs, pēc tam īstenojiet šo lēmumu: zonde, kas kontrolē lietojumprogrammas konteineru, tīkla politika, kas pēc noklusējuma noraida, vai abi. Bez viena no tiem lietojumprogramma startē, atrisina nosaukumus un sūta trafiku ārpus parastā mezgla ceļa, kamēr tunelis vēl pievienojas.

Šī plaisa veselā klasterī ir īsa un bojātā — pastāvīga, un tieši šo īpašību dod priekšroku uzbrucējs vai nejauša datu noplūde.

Savienojiet kārtību ar kļūmes testu. Nogaliniet sidecar un apstipriniet, ka lietojumprogramma zaudē paredzēto izeju, nevis klusi atkāpjas.

Iespējas, politikas un testēšana no lietojumprogrammas konteinera

To iespēju piešķiršana, kas vajadzīgas saskarņu izveidei un maršrutu mainīšanai, ir privilēģiju lēmums, un izolētam Pod piemērota privilēģija ne vienmēr automātiski ir piemērota mezgla stekā. Izmantojiet klastera atbalstītos tīkla un drošības politikas mehānismus un nepieņemiet, ka katra CNI vai politikas implementācija VPN saskarni apstrādā vienādi; atšķirības parādās tieši tajos kļūmes gadījumos, kas jums ir svarīgi.

Testējiet no īstā lietojumprogrammas konteinera ar jauniem pieprasījumiem uz privātu galamērķi, klastera pakalpojumu un publisko internetu. Tests no sidecar pierāda, ka tunelis darbojas, nevis to, ka lietojumprogramma sasniedz to, kas tai vajadzīgs.

Dokumentējiet klastera tīkla pieņēmumus blakus VPN konfigurācijai. Tad darba slodzes pārvietošana uz citu klasteri ir maršrutu plāna pārbaudes vingrinājums, nevis attēla maiņa, kas klusi pārstāj darboties.