VPN ya Pod katika Kubernetes dhidi ya lango la kutoka: handaki ni ya nani?

Unasambaza Pod inayoitwa vpn-gateway, unaelekeza mteja wa majaribio kwenye anwani yake na unaona pakiti zikitoweka. Hakuna kitu kibaya kwenye manifest na kubelet haina malalamiko. Sababu ni ya kimuundo, si ya usanidi: Kubernetes humpa kila Pod nafasi yake ya majina ya mtandao, kwa hivyo jina, lebo au nafasi ya majina ya API inayoshirikiwa haibadilishi chochote kuhusu mahali pakiti zinaenda. Kwa hivyo uamuzi wa jinsi trafiki ya VPN inatoka kwenye nguzo huanza na swali kuhusu umiliki, si kuhusu picha za kontena.

Mbinu mbili hushughulikia usambazaji mwingi halisi, na hazibadilishani. Moja huweka handaki ndani ya nafasi ya majina ya mtandao ya mzigo wa kazi wenyewe. Nyingine humwomba CNI aongoze trafiki iliyochaguliwa kupitia nodi ya lango iliyoteuliwa. Hushindwa kwa namna tofauti, hupanda kwa namna tofauti na hujibu kwa timu tofauti, ambayo ndiyo sababu swali la kontena huzalisha mabishano ambayo hayamaliziki kamwe.

Mpaka wa Pod ni nafasi ya majina, si mwenyeji wa kuruka

Nafasi ya majina ya mtandao ya Linux inamiliki violesura vyake, anwani zake, njia zake na kanuni zake za firewall, na kila Pod hupata moja. Kontena zilizo ndani ya Pod hiyo hujiunga nayo, na ndiyo sababu kontena saidizi linaweza kuandika upya njia ambazo programu hufuata baadaye. Pod jirani ina staki inayofanana kwa kuonekana lakini iliyotengana kabisa. Hakuna jedwali la pamoja ambalo Pod lango inaweza kurithi, na hakuna uhawilishaji wa kimojawapo wa trafiki kutoka nafasi moja ya majina hadi nyingine.

Ndiyo sababu muundo wa Pod-lango hufanya kazi tu wakati kitu kilicho juu kinatuma pakiti kwake kwa kweli: Service, njia isiyobadilika kwenye nodi au sera ya uelekezaji katika CNI. Anwani peke yake haivuti chochote.

Handaki kwa kila Pod hununua nini, na hugharimu nini

Handaki linaloendesha katika nafasi ya majina ya mzigo wa kazi humpa mzigo huo utambulisho wake wa mteja, ambao huduma nyingi za ufikiaji wa mbali huhitaji kabla ya kuidhinisha au kuhesabu kikao. Eneo la uharibifu pia hubaki la ndani: handaki lililovunjika huondoa Deployment moja badala ya njia iliyoshirikiwa inayotumiwa na kila kitu. Jinsi linavyoendesha hutegemea utekelezaji, na hapa ndipo watu hukisia vibaya.

Usanidi unaohitaji hali ya kernel pekee unaweza kumalizika katika kontena init na kutoka. Daemon ya nafasi ya mtumiaji ambayo lazima ibaki hai kwa muda wote wa Pod inahitaji umbo la kontena init linaloweza kuanzishwa upya lililoletwa kama sidecar asilia katika Kubernetes 1.29, na tofauti hiyo inatoka kwenye utekelezaji wa handaki na si kwa ladha. Gharama ya muundo huu ni kunakiliwa: kila replika huthibitisha, hupokea anwani yake ya handaki na huchukua nafasi ya kikao cha mbali, kwa hivyo tukio la upanuzi wa kiotomatiki huwa tukio la uwezo upande wa pili wa kiungo. Kunakili kitambulisho kimoja kwenye replika zote hakuondoi gharama hiyo, huondoa njia ya ukaguzi. Uwezo pia unastahili uchunguzi huo, kwa sababu handaki linalotaka NET_ADMIN katika nafasi yake ya majina halina sababu ya kurithi mamlaka ya mwenyeji wote kutoka kwa mfano wenye privileged: true.

Wakati CNI inamiliki kutoka

Ikiwa CNI inaunga mkono, lango la kutoka huchagua trafiki kwa mzigo wa kazi na masafa ya lengwa, kisha hupeleka kupitia nodi zilizochaguliwa chini ya anwani moja ya chanzo inayotabirika. Toleo la Cilium ndilo rejeleo la kawaida, na nyaraka zake husema wazi kwamba kipengele kinahitaji usanidi maalum wa Cilium pamoja na nodi za lango zilizopewa violesura na anwani sahihi. Pia inataja kipindi cha mwanzo baada ya Pod kuundwa ambapo uelekezaji bado hautekelezwi, jambo ambalo ni ingizo la usanifu na si tanbihi.

Soma ucheleweshaji huo dhidi ya ahadi yako mwenyewe. Ikiwa kanuni ni kwamba hakuna trafiki inayoweza kutoka kwa njia nyingine, Pod mpya inayotuma wakati wa pengo tayari imeivunja, kwa hivyo mfululizo wa kuanza unahitaji jibu lake: zuia programu hadi sera itekelezwe, au kubali dirisha na uliandike.

Wehuka dai liwe jembamba. Lango la kutoka huchagua na kutafsiri njia. Haliwezi kumaliza VPN, na hailifanyi nguzo kuwa mteja wa mtandao wako wa mbali bila muunganisho unaoungwa mkono nyuma yake.

Tafsiri hubadilisha kwa utulivu kile upande wa mbali unachokiona

Mara lango linapoandika upya chanzo, anwani za kila Pod hupotea, kwa hivyo orodha ya ruhusa inayotegemea utambulisho huwa orodha inayotegemea anwani moja iliyoshirikiwa. Hii ni kubadilishana na si kasoro: kanuni chache za kudumisha, uhusishaji mbaya zaidi wakati kitu kinapotenda vibaya.

Uthibitishaji wa kiwango cha programu na uwekaji kumbukumbu wa maombi lazima kubebe kile mtandao usivyoripoti tena. Chukulia uwezo wa lango na uingizwaji wake kama miundombinu iliyoshirikiwa, kwa sababu kuwasha upya nodi moja sasa hukatiza kila mzigo wa kazi nyuma yake, na angalia njia ya kurudi mapema: upande wa mbali lazima ujue jinsi ya kufikia anwani iliyotafsiriwa, kwa kawaida kupitia njia au NAT ambayo mtu, si manifest, lazima amiliki. Upangaji wa anwani pia ni sehemu ya hapa, kwa sababu masafa yanayopishana ya nguzo na ya mbali huvunja miundo yote miwili na kupitisha IPv6 hakuhalalishi mpango unaopingana.

Amua kwa umiliki, kisha jaribu kushindwa uliyoahidi

Chagua handaki kwa kila Pod wakati huduma ya mbali inathibitisha mizigo binafsi ya kazi, wakati Deployment chache tu zinahitaji kiungo, na wakati kushindwa kunapaswa kubaki ndani. Chagua lango wakati timu ya mtandao tayari inamiliki njia, wakati mizigo mingi inashiriki lengo moja, na wakati anwani thabiti ya chanzo ndiyo madhumuni yote ya zoezi.

Vyovyote vile, thibitisha sifa uliyouza na si hali tulivu. Unda Pod, iache itume mara moja na tazama sekunde za kwanza ikiwa ahadi ilikuwa kwamba hakuna kinachotoroka kutoka kwenye handaki. Panda hadi replika tano na uhesabu vikao ambavyo upande wa mbali unaripoti ikiwa ahadi ilikuwa utambulisho kwa kila mzigo wa kazi. Ukaguzi huo mbili hufichua mipaka ya mbinu haraka zaidi kuliko mapitio ya manifest, na hukuambia timu gani inamiliki tukio linalofuata.