VPN í Pod í Kubernetes á móti útgangsgátt: hver á göngin?
Pod er sitt eigið netnafnrými, þannig að raunverulega valið er hvaða lag á göngin: auðkenni fyrir hvert vinnuálag eða CNI-stýrður útgangur með einni sameiginlegri uppsprettu.
Þú setur upp Pod sem heitir vpn-gateway, beinir prófunarviðmóti að heimilisfangi þess og sérð pakkana hverfa. Ekkert í manifestinu er rangt og kubelet hefur enga kvörtun. Ástæðan er byggingarleg en ekki stillingarleg: Kubernetes gefur hverju Pod sínu eigin netnafnrými, þannig að nafn, merki eða sameiginlegt API-nafnrými breytir engu um hvert pakkarnir fara. Því hefst ákvörðunin um hvernig VPN-umferð fer út úr klasanum með spurningu um eignarhald, ekki um gámamyndir.
Tvær aðferðir ná yfir flestar raunverulegar uppsetningar og eru ekki skiptanlegar. Önnur setur göngin inn í eigið netnafnrými vinnuálagsins. Hin biður CNI um að beina völdum umferðum gegnum tiltekinn gáttahnút. Þær mistakast á mismunandi hátt, skala á mismunandi hátt og heyra undir mismunandi teymi, og þess vegna framleiðir gámuspurningin venjulega rökræður sem aldrei ljúka.
Mörk Pod eru nafnrými, ekki stökkshýsill
Linux-netnafnrými á sín eigin tengi, heimilisföng, leiðir og eldveggsreglur, og hvert Pod fær eitt. Gámar inni í því Pod ganga inn í það, og þess vegna getur hjálpargámur endurskrifað leiðir sem forritið fylgir síðan. Nágranna-Pod hefur sams konar stafla en algjörlega aðskilinn. Það er engin sameiginleg tafla sem gáttar-Pod getur erft, og engin óbeint afhending umferðar frá einu nafnrými til annars.
Þess vegna virkar gáttar-Pod mynstrið aðeins þegar eitthvað ofar í keðjunni sendir raunverulega pakka til þess: Service, kyrr leið á hnútnum eða stýringarstefna í CNI. Heimilisfang eitt og sér laðar ekkert að.
Hvað göng fyrir hvert Pod kaupa og hvað þau kosta
Göng sem keyra í nafnrými vinnuálagsins gefa því vinnuálagi sitt eigið viðmótsauðkenni, sem mörg fjartengingarþjónustur krefjast áður en þær heimila eða gera upp lotu. Skemmdarradiusinn helst einnig staðbundinn: brotin göng slökkva á einu Deployment í stað sameiginlegu leiðarinnar sem allt notar. Hvernig þau keyra fer eftir útfærslunni, og það er hér sem fólk giskar rangt.
Uppsetning sem þarf aðeins kjarnastöðu getur klárast í init-gámi og farið út. Notendarýmisdaemon sem verður að vera á lífi alla ævi Podsins þarf endurræsanlega init-gáma myndina sem var kynnt sem innfæddur hliðargámur í Kubernetes 1.29, og sá munur kemur frá útfærslu ganganna en ekki smekk. Kostnaður þessa líkans er tvítekning: hvert eintak auðkennir sig, fær sitt eigið gagnsheimilisfang og tekur fjarlotu, þannig að sjálfvirk stækkun verður afkastaatburður hinum megin við tenginguna. Að afrita eitt skírteini í öll eintök fjarlægir ekki þann kostnað, það fjarlægir endurskoðunarslóðina. Heimildir eiga skilið sömu skoðun, því göng sem vilja NET_ADMIN í eigin nafnrými hafa enga ástæðu til að erfa vald yfir öllum hýsinum úr dæmi með privileged: true.
Þegar CNI á útganginn
Ef CNI styður það velur útgangsgátt umferð eftir vinnuálagi og áfangasviði og sendir hana síðan gegnum valda hnúta undir einu fyrirsjáanlegu uppsprettuheimilisfangi. Útgáfa Cilium er algenga viðmiðið og skjöl hennar segja skýrt að eiginleikinn krefjist sérstakrar Cilium-stillingar auk gáttahnúta með réttum tengjum og heimilisföngum. Hún nefnir einnig upphafstímabil eftir að Pod er búið til þar sem beitingin er ekki enn virk, sem er hönnunarinntak en ekki neðanmálsgrein.
Lestu þá seinkun gagnvart eigin loforði. Ef reglan er að engin umferð megi fara aðra leið hefur nýtt Pod sem sendir á meðan á bilinu stendur þegar brotið hana, svo ræsingarferlið þarf sitt eigið svar: halda forritinu þar til stefnan gildir, eða samþykkja gluggann og skjalfesta hann.
Haltu fullyrðingunni þröngri. Útgangsgátt velur og þýðir leið. Hún endar ekki VPN og gerir klasann ekki að viðmóti fjarnetsins þíns án studdrar tengingar á bak við.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
Þýðing breytir hljóðlega því sem fjarlæga hliðin sér
Þegar gáttin endurskrifar uppsprettuna eru heimilisföng hvers Pod horfin, svo leyfislisti sem byggir á auðkenni verður listi sem byggir á einu sameiginlegu heimilisfangi. Þetta er skipti en ekki galli: færri reglur til að viðhalda, grófari eignun þegar eitthvað hegðar sér illa.
Auðkenning á forritslaginu og beiðnaskráning verða að bera það sem netið greinir ekki lengur frá. Meðhöndlaðu afkastagetu og endurnýjun gáttarinnar sem sameiginlega innviði, því endurræsing eins hnúts truflar nú hvert vinnuálag á bak við hann, og athugaðu afturleiðina snemma: fjarlæga endinn verður að vita hvernig á að ná þýdda heimilisfanginu, venjulega um leið eða NAT sem maður, ekki manifest, verður að eiga. Heimilisfangaáætlun á líka hér heima, því skarast klasa- og fjarsvið brjóta hvort tveggja líkanið og upptaka IPv6 afsakar ekki misvísandi áætlun.
Ákveddu eftir eignarhaldi og prófaðu svo bilunina sem þú lofaðir
Veldu göng fyrir hvert Pod þegar fjarlæga þjónustan auðkennir einstök vinnuálag, þegar aðeins fá Deployment þurfa tenginguna og þegar bilun á að vera staðbundin. Veldu gáttina þegar netteymi á leiðina þegar, þegar mörg vinnuálög deila einum áfangastað og þegar stöðugt uppsprettuheimilisfang er allur tilgangur æfingarinnar.
Hvort sem er, staðfestu eiginleikann sem þú seldir en ekki stöðuga ástandið. Búðu til Pod, láttu það senda strax og fylgstu með fyrstu sekúndunum ef loforðið var að ekkert slyppi úr göngunum. Skalaðu í fimm eintök og teldu loturnar sem fjarlægi endinn greinir frá ef loforðið var auðkenni fyrir hvert vinnuálag. Þessar tvær athuganir afhjúpa mörk aðferðarinnar miklu fyrr en yfirferð manifestsins, og þær segja þér hvaða teymi á næsta atvik.