Kubernetesi Podi VPN versus väljundvärav: kellele kuulub tunnel?

Paigutate Podi nimega vpn-gateway, suunate testkliendi selle aadressile ja näete, kuidas paketid kaovad. Manifestis pole midagi valesti ja kubeletil pole midagi ette heita. Põhjus on struktuurne, mitte konfiguratsiooniline: Kubernetes annab igale Podile oma võrgu nimeruumi, seega nimi, silt või jagatud API nimeruum ei muuda midagi selles, kuhu paketid lähevad. Otsus, kuidas VPN-liiklus klastrist väljub, algab seega omandiõiguse küsimusest, mitte konteineripiltide küsimusest.

Kaks mehhanismi katavad enamiku reaalsetest juurutustest ja need ei ole vahetatavad. Üks paneb tunneli töökoormuse enda võrgu nimeruumi. Teine palub CNI-l suunata valitud liiklus määratud väravasõlme kaudu. Need ei feili ühtemoodi, skaleeruvad erinevalt ja vastavad eri meeskondadele, mistõttu konteineriküsimus tekitab tavaliselt vaidlusi, mis kunagi ei lahene.

Podi piir on nimeruum, mitte hüppehost

Linuxi võrgu nimeruum omab oma liideseid, aadresse, marsruute ja tulemüürireegleid ning iga Pod saab ühe. Selle Podi sees olevad konteinerid ühinevad sellega ja täpselt seepärast saab abikonteiner marsruute ümber kirjutada, mida rakendus seejärel järgib. Naaber-Podil on identne väljanägemisega, kuid täiesti eraldiseisev virn. Puudub jagatud tabel, mille värava-Pod saaks pärida, ja puudub liikluse kaudne üleandmine ühest nimeruumist teise.

Seepärast töötab värava-Podi muster alles siis, kui midagi ülesvoolu saadab sinna tegelikult pakette: Service, sõlme staatiline marsruut või CNI suunamispoliitika. Üksi aadress ei tõmba midagi.

Mida tunnel iga Podi kohta annab ja mida see maksab

Töökoormuse nimeruumis töötav tunnel annab sellele töökoormusele oma kliendiidentiteedi, mida paljud kaugjuurdepääsuteenused nõuavad enne sessiooni volitamist või arvestamist. Kahjuringkond jääb samuti kohalikuks: katkine tunnel võtab maha ühe Deploymenti, mitte jagatud tee, mida kõik kasutavad. Kuidas see töötab, sõltub teostusest, ja just siin inimesed eksivad.

Seadistus, mis vajab ainult kerneli olekut, võib lõppeda init-konteineris ja väljuda. Kasutajaruumi deemon, mis peab Podi eluea jooksul elus püsima, vajab taaskäivitatava init-konteineri vormi, mis võeti Kubernetes 1.29-s kasutusele natiivse kõrvalkonteinerina, ja see erinevus tuleb tunneli teostusest, mitte maitsest. Selle mudeli hind on dubleerimine: iga replika autendib end, saab oma tunneli aadressi ja hõivab kaugsessiooni koha, nii et automaatse skaleerimise sündmus muutub võimsussündmuseks lingi teisel poolel. Ühe mandaadi kopeerimine kõikidesse replikatesse ei kõrvalda seda hinda, see kõrvaldab auditeerimisjälje. Õigused väärivad sama kontrolli, sest tunnel, mis tahab oma nimeruumis NET_ADMIN, ei tohiks pärida kogu hosti ulatust privileged: true näites.

Kui CNI omab hoopis väljundit

Kui CNI seda toetab, valib väljundvärav liikluse töökoormuse ja sihtvahemiku järgi ning saadab selle seejärel valitud sõlmede kaudu ühe etteaimatava lähteaadressi all. Ciliumi versioon on tavaline viide ja selle dokumentatsioon ütleb selgelt, et funktsioon nõuab spetsiifilist Ciliumi konfiguratsiooni pluss väravasõlmi, mis on varustatud õigete liideste ja aadressidega. See märgib ka algperioodi pärast Podi loomist, mil suunamine veel ei kehti, mis on disaini sisend, mitte joonealune märkus.

Lugege seda viivitust oma lubaduse vastu. Kui reegel on, et ükski liiklus ei tohi teist teed pidi väljuda, siis on selle vahe ajal saatev uus Pod selle juba rikkunud, seega vajab käivitusjärjekord oma vastust: hoidke rakendust kinni, kuni poliitika rakendub, või aktsepteerige aken ja dokumenteerige see.

Hoidke väidet kitsana. Väljundvärav valib ja tõlgib tee. See ei lõpeta VPN-i ega muuda klastrit teie kaugvõrgu kliendiks ilma toetatud ühenduseta selle taga.

Tõlkimine muudab vaikselt seda, mida kaugpool näeb

Kui värav lähtekoha ümber kirjutab, kaovad iga Podi aadressid, seega identiteedil põhinev lubatud loend muutub ühel jagatud aadressil põhinevaks loendiks. See on vahetus, mitte defekt: vähem reegleid hooldada, jämedam omistamine, kui miski käitub halvasti.

Rakenduse tasandi autentimine ja päringulogimine peavad kandma seda, mida võrk enam ei raporteeri. Käsitlege värava võimsust ja asendamist jagatud taristuna, sest ühe sõlme taaskäivitamine katkestab nüüd iga töökoormuse selle taga, ja kontrollige tagasiteed varakult: kaugots peab teadma, kuidas tõlgitud aadressile jõuda, tavaliselt marsruudi või NAT-i kaudu, mida peab omama inimene, mitte manifest. Aadresside planeerimine kuulub samuti siia, sest kattuvad klastri- ja kaugvahemikud rikuvad mõlemat mudelit ja IPv6 kasutuselevõtt ei vabanda vastuolulist plaani.

Otsustage omandi järgi, seejärel testige lubatud tõrget

Valige tunnel iga Podi kohta, kui kaugteenus autendib üksikuid töökoormusi, kui linki vajavad vaid mõned Deploymentid ja kui tõrge peaks jääma kohalikuks. Valige värav, kui võrgumeeskond juba omab teed, kui paljud töökoormused jagavad üht sihti ja kui stabiilne lähteaadress on kogu harjutuse mõte.

Ükskõik kuidas, kontrollige omadust, mille müüsite, mitte püsiseisundit. Looge Pod, laske sellel kohe saata ja jälgige esimesi sekundeid, kui lubadus oli, et tunnelist ei pääse miski välja. Skaleerige viiele replikale ja loendage sessioonid, millest kaugots teata, kui lubadus oli identiteet iga töökoormuse kohta. Need kaks kontrolli paljastavad mehhanismi piirid palju kiiremini kui manifesti ülevaatus, ja need ütlevad, milline meeskond omab järgmist juhtumit.