Pod VPN Kubernetes pret izejas vārteju: kam pieder tunelis?

Jūs izvietojat Pod ar nosaukumu vpn-gateway, vēršat testa klientu uz tā adresi un redzat, kā paketes pazūd. Manifestā nekas nav nepareizi, un kubelet nav iebildumu. Iemesls ir strukturāls, nevis konfigurācijas: Kubernetes katram Pod piešķir savu tīkla nosaukumtelpu, tāpēc nosaukums, birka vai kopīga API nosaukumtelpa neko nemaina pakešu galamērķī. Tāpēc lēmums par to, kā VPN trafiks atstāj klasteri, sākas ar jautājumu par īpašumtiesībām, nevis par konteineru attēliem.

Divas mehānismi aptver lielāko daļu reālo izvietojumu, un tie nav savstarpēji aizstājami. Viens ievieto tuneli darba sloga paša tīkla nosaukumtelpā. Otrs lūdz CNI virzīt atlasīto trafiku caur norādītu vārtejas mezglu. Tie neizdodas atšķirīgi, mērogojas atšķirīgi un atbild dažādām komandām, tāpēc konteinera jautājums parasti rada strīdus, kas nekad nebeidzas.

Pod robeža ir nosaukumtelpa, nevis lēciena resursdators

Linux tīkla nosaukumtelpa pārvalda savus interfeisus, adreses, maršrutus un ugunsdrošības noteikumus, un katrs Pod saņem vienu. Konteineri šajā Pod pievienojas tai, un tieši tāpēc palīgkonteiners var pārrakstīt maršrutus, kurus pēc tam ievēro lietojumprogramma. Blakus esošajam Pod ir identiski izskatīgs, bet pilnīgi atsevišķs steks. Nav kopīgas tabulas, ko vārtejas Pod varētu mantot, un nav netiešas trafika nodošanas no vienas nosaukumtelpas citā.

Tāpēc vārtejas Pod modelis darbojas tikai tad, kad kaut kas augstāk tiešām sūta tam paketes: Service, statisks maršruts mezglā vai virzīšanas politika CNI. Viena adrese vien neko nepiesaista.

Ko tunelis katram Pod dod un cik tas maksā

Tunelis, kas darbojas darba sloga nosaukumtelpā, piešķir šim slogam savu klienta identitāti, ko daudzi attālinātās piekļuves pakalpojumi pieprasa pirms sesijas autorizēšanas vai uzskaites. Arī bojājuma rādiuss paliek lokāls: bojāts tunelis izslēdz vienu Deployment, nevis kopīgo ceļu, ko izmanto viss. Kā tas darbojas, ir atkarīgs no ieviešanas, un tieši šeit cilvēki min nepareizi.

Uzstādījums, kam nepieciešams tikai kodola stāvoklis, var pabeigt init konteinerā un iziet. Lietotāja telpas dēmons, kam jāpaliek dzīvam visu Pod mūžu, prasa atsāknējamu init konteinera formu, kas tika ieviesta kā vietējs blakuskonteiners Kubernetes 1.29, un šī atšķirība nāk no tuneļa ieviešanas, nevis no gaumes. Šī modeļa izmaksas ir dublēšanās: katra replika autentificējas, saņem savu tuneļa adresi un aizņem attālinātās sesijas vietu, tāpēc automātiskās mērogošanas notikums kļūst par jaudas notikumu savienojuma otrā pusē. Viena akreditācijas datu kopēšana visās replikās šīs izmaksas neceļ, tā noņem audita pēdas. Arī tiesības pelnījušas to pašu pārbaudi, jo tunelim, kas vēlas NET_ADMIN savā nosaukumtelpā, nav pamata mantot visas resursdatora varas no piemēra ar privileged: true.

Kad CNI pārvalda izeju

Ja CNI to atbalsta, izejas vārteja atlasa trafiku pēc darba sloga un galamērķa diapazona, pēc tam sūta to caur atlasītiem mezgliem zem vienas paredzamas avota adreses. Cilium versija ir ierastā atsauce, un tās dokumentācija skaidri norāda, ka funkcijai nepieciešama konkrēta Cilium konfigurācija un vārtejas mezgli ar pareizajiem interfeisiem un adresēm. Tā arī min sākotnējo periodu pēc Pod izveides, kad virzīšana vēl netiek piemērota, un tas ir dizaina ievads, nevis zemsvītras piezīme.

Lasiet šo kavēšanos pret savu solījumu. Ja noteikums ir tāds, ka neviens trafiks nedrīkst iziet pa citu ceļu, jauns Pod, kas sūta spraugas laikā, to jau ir pārkāpis, tāpēc palaišanas secībai ir vajadzīga sava atbilde: aizturēt lietojumprogrammu, līdz politika stājas spēkā, vai pieņemt logu un dokumentēt to.

Turiet apgalvojumu šauru. Izejas vārteja izvēlas un tulko ceļu. Tā neizbeidz VPN un nepārvērš klasteri par jūsu attālinātā tīkla klientu bez atbalstīta savienojuma aiz tā.

Tulkošana klusi maina to, ko redz attālinātā puse

Tiklīdz vārteja pārraksta avotu, katram Pod piederošās adreses pazūd, tāpēc identitātē balstīts atļauto saraksts kļūst par sarakstu, kas balstīts uz vienu kopīgu adresi. Tā ir maiņa, nevis defekts: mazāk noteikumu uzturēšanai, rupjāka attiecināšana, kad kaut kas uzvedas slikti.

Lietojumprogrammas līmeņa autentifikācijai un pieprasījumu reģistrēšanai jānes tas, ko tīkls vairs neziņo. Uztveriet vārtejas jaudu un nomaiņu kā kopīgu infrastruktūru, jo viena mezgla pārstartēšana tagad pārtrauc katru darba slogu aiz tā, un pārbaudiet atgriešanās ceļu agri: attālinātajai pusei jāzina, kā sasniegt tulkoto adresi, parasti caur maršrutu vai NAT, kam jāpieder cilvēkam, nevis manifestam. Arī adrešu plānošana pieder šeit, jo pārklājošie klastera un attālinātie diapazoni salauž abus modeļus, un IPv6 ieviešana neattaisno pretrunīgu plānu.

Izlemiet pēc īpašumtiesībām, tad pārbaudiet apsolīto kļūmi

Izvēlieties tuneli katram Pod, kad attālinātais pakalpojums autentificē atsevišķus darba slokus, kad saite nepieciešama tikai dažiem Deployment, un kad kļūmei jāpaliek lokālai. Izvēlieties vārteju, kad tīkla komanda jau pārvalda ceļu, kad daudzi slogi dala vienu galamērķi, un kad stabila avota adrese ir visa vingrinājuma jēga.

Jebkurā gadījumā pārbaudiet pārdoto īpašību, nevis līdzsvara stāvokli. Izveidojiet Pod, ļaujiet tam nekavējoties sūtīt un vērojiet pirmās sekundes, ja solījums bija, ka nekas neizbēg no tuneļa. Mērogojiet līdz piecām replikām un saskaitiet sesijas, par kurām ziņo attālinātā puse, ja solījums bija identitāte katram slogam. Šīs divas pārbaudes atklāj mehānisma robežas daudz ātrāk nekā manifesta pārskatīšana, un tās pasaka, kurai komandai pieder nākamais incidents.