Kiini cha hadithi kuhusu msimamizi maarufu wa kifurushi cha Kubernetes kinaweza kuonyeshwa kwa kutumia emoji:
- kisanduku ni Helm (ambacho ndicho kitu kilicho karibu zaidi na toleo la hivi punde la Emoji);
- lock - usalama;
- mtu mdogo ndiye suluhisho la shida.
Kwa kweli, kila kitu kitakuwa ngumu zaidi, na hadithi imejaa maelezo ya kiufundi kuhusu Jinsi ya kufanya Helm salama.
- Kwa kifupi Helm ni nini ikiwa haukujua au kusahau. Inasuluhisha shida gani na iko wapi katika mfumo wa ikolojia.
- Wacha tuangalie usanifu wa Helm. Hakuna mazungumzo kuhusu usalama na jinsi ya kufanya chombo au suluhisho kuwa salama zaidi yamekamilishwa bila kuelewa usanifu wa kijenzi.
- Wacha tujadili vipengele vya Helm.
- Swali linalowaka zaidi ni siku zijazo - toleo jipya la Helm 3.
Kila kitu katika makala haya kinatumika kwa Helm 2. Toleo hili linatolewa kwa sasa na lina uwezekano mkubwa ndilo unalotumia sasa, na ni toleo ambalo lina hatari za usalama.
Kuhusu mzungumzaji: Alexander Khayorov () imekuwa ikiendelezwa kwa miaka 10, na kusaidia kuboresha maudhui na kujiunga na kamati . Sasa anafanya kazi katika Chainstack kama kiongozi wa maendeleo - huu ni mseto kati ya msimamizi wa maendeleo na mtu ambaye ana jukumu la kutoa matoleo ya mwisho. Hiyo ni, iko kwenye uwanja wa vita, ambapo kila kitu hutokea tangu kuundwa kwa bidhaa hadi uendeshaji wake.
Chainstack ni kianzishaji kidogo, kinachokua kikamilifu ambacho dhamira yake ni kuwawezesha wateja kusahau kuhusu miundombinu na matatizo ya uendeshaji wa programu zilizogatuliwa; timu ya maendeleo iko Singapore. Usiulize Chainstack kuuza au kununua cryptocurrency, lakini toa kuzungumza juu ya mifumo ya blockchain ya biashara, na watakujibu kwa furaha.
Helm
Hiki ni meneja wa kifurushi (chati) cha Kubernetes. Njia angavu na ya ulimwengu wote ya kuleta programu kwenye kundi la Kubernetes.
Bila shaka, tunazungumza kuhusu mbinu ya kimuundo na kiviwanda zaidi kuliko kuunda maonyesho yako ya YAML na kuandika huduma ndogo ndogo.
Helm ndio bora zaidi ambayo inapatikana kwa sasa na maarufu.
Kwa nini Helm? Kimsingi kwa sababu inaungwa mkono na CNCF. Cloud Native ni shirika kubwa na ndiyo kampuni mama ya miradi ya Kubernetes, etcd, Fluentd na mingineyo.
Ukweli mwingine muhimu ni kwamba Helm ni mradi maarufu sana. Nilipoanza kuzungumza juu ya jinsi ya kufanya Helm kuwa salama mnamo Januari 2019, mradi huo ulikuwa na nyota elfu kwenye GitHub. Kufikia Mei kulikuwa na elfu 12 kati yao.
Watu wengi wanavutiwa na Helm, kwa hivyo hata ikiwa bado hutumii, utafaidika kwa kujua kuhusu usalama wake. Usalama ni muhimu.
Timu ya msingi ya Helm inaungwa mkono na Microsoft Azure na kwa hivyo ni mradi thabiti, tofauti na wengine wengi. Kutolewa kwa Helm 3 Alpha 2 katikati ya Julai kunaonyesha kuwa kuna watu wengi sana wanaofanya kazi kwenye mradi huo, na wana hamu na nguvu ya kukuza na kuboresha Helm.
Helm hutatua matatizo kadhaa ya mizizi ya usimamizi wa programu katika Kubernetes.
- Ufungaji wa maombi. Hata programu kama vile "Hujambo, Ulimwengu" kwenye WordPress tayari ina huduma kadhaa, na unataka kuzifunga pamoja.
- Kudhibiti ugumu unaokuja na kudhibiti programu hizi.
- Mzunguko wa maisha ambao hauishii baada ya programu kusakinishwa au kutumwa. Inaendelea kuishi, inahitaji kusasishwa, na Helm husaidia na hili na inajaribu kuleta hatua na sera zinazofaa kwa hili.
Bagging imeandaliwa kwa njia ya wazi: kuna metadata kwa mujibu kamili na kazi ya meneja wa kawaida wa mfuko wa Linux, Windows au MacOS. Hiyo ni, hifadhi, utegemezi wa vifurushi mbalimbali, taarifa ya meta kwa programu, mipangilio, vipengele vya usanidi, indexing ya habari, nk. Helm inakuwezesha kupata na kutumia haya yote kwa programu.
Usimamizi wa Utata. Ikiwa una programu nyingi za aina moja, basi parameterization inahitajika. Violezo vinatokana na hili, lakini ili kuepuka kulazimika kuja na njia yako mwenyewe ya kuunda violezo, unaweza kutumia kile ambacho Helm hutoa nje ya kisanduku.
Maombi Lifecycle Management - kwa maoni yangu, hili ndilo swali la kuvutia zaidi na lisilotatuliwa. Hii ndiyo sababu nilikuja Helm nyuma katika siku. Tulihitaji kuweka jicho kwenye mzunguko wa maisha ya maombi na tulitaka kuhamisha CI/CD na mizunguko ya maombi kwenye dhana hii.
Helm inakuwezesha:
- kusimamia kupelekwa, kuanzisha dhana ya usanidi na marekebisho;
- kutekeleza urejeshaji kwa mafanikio;
- tumia ndoano kwa matukio tofauti;
- ongeza ukaguzi wa ziada wa programu na ujibu matokeo yao.
Aidha Helm ina "betri" - idadi kubwa ya mambo ya kitamu ambayo yanaweza kujumuishwa katika mfumo wa programu-jalizi, kurahisisha maisha yako. Plugins zinaweza kuandikwa kwa kujitegemea, zimetengwa kabisa na hazihitaji usanifu wa usawa. Ikiwa unataka kutekeleza kitu, napendekeza kuifanya kama programu-jalizi, na ikiwezekana kuijumuisha kwenye mkondo wa juu.
Helm inategemea dhana kuu tatu:
- Repo ya Chati - maelezo na safu mbalimbali za vigezo vinavyowezekana kwa faili yako ya maelezo.
- Sanidi - Hiyo ni, maadili ambayo yatatumika (maandishi, nambari za nambari, nk).
- Achilia hukusanya vipengele viwili vya juu, na kwa pamoja vinageuka kuwa Kutolewa. Matoleo yanaweza kubadilishwa, na hivyo kufikia mzunguko wa maisha uliopangwa: ndogo wakati wa ufungaji na kubwa wakati wa kuboresha, kupunguza au kurejesha.
Usanifu wa helm
Mchoro kimawazo unaonyesha usanifu wa hali ya juu wa Helm.
Acha nikukumbushe kwamba Helm ni kitu kinachohusiana na Kubernetes. Kwa hivyo, hatuwezi kufanya bila nguzo ya Kubernetes (mstatili). Sehemu ya kube-apiserver inakaa juu ya bwana. Bila Helm tuna Kubeconfig. Helm huleta binary moja ndogo, ikiwa unaweza kuiita, Helm CLI shirika, ambayo imewekwa kwenye kompyuta, kompyuta ndogo, mfumo mkuu - kwenye chochote.
Lakini hii haitoshi. Helm ina sehemu ya seva inayoitwa Tiller. Inawakilisha masilahi ya Helm ndani ya nguzo; ni maombi ndani ya nguzo ya Kubernetes, kama nyingine yoyote.
Sehemu inayofuata ya Chati Repo ni hazina iliyo na chati. Kuna hazina rasmi, na kunaweza kuwa na hazina ya kibinafsi ya kampuni au mradi.
Mwingiliano
Hebu tuangalie jinsi vipengele vya usanifu vinavyoingiliana tunapotaka kusakinisha programu kwa kutumia Helm.
- Tunazungumza
Helm install, fikia hazina (Chati Repo) na upate chati ya Helm.
- Huduma ya Helm (Helm CLI) huingiliana na Kubeconfig ili kubaini ni nguzo gani ya kuwasiliana.
- Baada ya kupokea habari hii, shirika linarejelea Tiller, ambayo iko kwenye nguzo yetu, kama programu.
- Tiller huita Kube-apiserver kutekeleza vitendo katika Kubernetes, kuunda baadhi ya vitu (huduma, maganda, nakala, siri, n.k.).
Ifuatayo, tutachanganya mchoro ili kuona vekta ya kushambulia ambayo usanifu wote wa Helm kwa ujumla unaweza kuonyeshwa. Na kisha tutajaribu kumlinda.
Vekta ya kushambulia
Jambo la kwanza linalowezekana dhaifu ni API ya upendeleo-user. Kama sehemu ya mpango huu, huyu ni mdukuzi ambaye amepata ufikiaji wa msimamizi kwa Helm CLI.
Mtumiaji wa API asiyebahatika inaweza pia kusababisha hatari ikiwa iko mahali fulani karibu. Mtumiaji kama huyo atakuwa na muktadha tofauti, kwa mfano, anaweza kusasishwa katika nafasi ya majina ya nguzo katika mipangilio ya Kubeconfig.
Vekta ya shambulio la kuvutia zaidi inaweza kuwa mchakato ambao unapatikana ndani ya kundi mahali fulani karibu na Tiller na unaweza kuipata. Hii inaweza kuwa seva ya wavuti au huduma ndogo inayoona mazingira ya mtandao wa nguzo.
Lahaja ya kigeni, lakini inayozidi kuwa maarufu, inahusisha Chati Repo. Chati iliyoundwa na mwandishi asiye mwaminifu inaweza kuwa na rasilimali zisizo salama, na utaikamilisha kwa kuichukua kwa imani. Au inaweza kuchukua nafasi ya chati unayopakua kutoka kwa hazina rasmi na, kwa mfano, kuunda nyenzo katika mfumo wa sera na kuongeza ufikiaji wake.
Wacha tujaribu kuzuia mashambulio kutoka pande zote nne na tujue ni wapi kuna shida katika usanifu wa Helm, na wapi, labda, hakuna.
Hebu kupanua mchoro, kuongeza vipengele zaidi, lakini kuweka vipengele vyote vya msingi.
Helm CLI huwasiliana na Chati Repo, huingiliana na Kubeconfig, na kazi huhamishiwa kwenye nguzo hadi sehemu ya Tiller.
Tiller inawakilishwa na vitu viwili:
- Tiller-deploy svc, ambayo inafichua huduma fulani;
- Tiller-deploy pod (katika mchoro katika nakala moja katika replica moja), ambayo mzigo mzima unaendesha, ambayo hufikia nguzo.
Itifaki na mipango tofauti hutumiwa kwa mwingiliano. Kwa mtazamo wa usalama, tunavutiwa zaidi na:
- Utaratibu ambao Helm CLI hufikia repo ya chati: ni itifaki gani, kuna uthibitishaji na nini kinaweza kufanywa nayo.
- Itifaki ambayo Helm CLI, kwa kutumia kubectl, inawasiliana na Tiller. Hii ni seva ya RPC iliyosakinishwa ndani ya nguzo.
- Tiller yenyewe inaweza kufikiwa na huduma ndogo ndogo ambazo hukaa kwenye nguzo na kuingiliana na Kube-apiserver.
Hebu tujadili maeneo haya yote kwa utaratibu.
RBAC
Hakuna haja ya kuzungumza juu ya usalama wowote wa Helm au huduma nyingine yoyote ndani ya nguzo isipokuwa RBAC imewezeshwa.
Inaonekana kwamba hii sio pendekezo la hivi karibuni, lakini nina hakika kwamba watu wengi bado hawajawezesha RBAC hata katika uzalishaji, kwa sababu ni fujo nyingi na mambo mengi yanahitaji kusanidiwa. Hata hivyo, nakuhimiza kufanya hivi.
- mwanasheria wa tovuti kwa RBAC. Ina kiasi kikubwa cha vifaa vya kuvutia ambavyo vitakusaidia kuanzisha RBAC, onyesha kwa nini ni nzuri na jinsi ya kimsingi kuishi nayo katika uzalishaji.
Nitajaribu kueleza jinsi Tiller na RBAC hufanya kazi. Tiller hufanya kazi ndani ya nguzo chini ya akaunti fulani ya huduma. Kwa kawaida, ikiwa RBAC haijasanidiwa, hii itakuwa mtumiaji mkuu. Katika usanidi wa kimsingi, Tiller atakuwa msimamizi. Hii ndiyo sababu inasemekana kwamba Tiller ni njia ya SSH kwa nguzo yako. Kwa kweli, hii ni kweli, kwa hivyo unaweza kutumia akaunti tofauti ya huduma iliyojitolea badala ya Akaunti ya Huduma Chaguomsingi kwenye mchoro hapo juu.
Unapoanzisha Helm na kuisakinisha kwenye seva kwa mara ya kwanza, unaweza kuweka akaunti ya huduma kwa kutumia --service-account. Hii itakuruhusu kutumia mtumiaji aliye na seti ya chini inayohitajika ya haki. Ukweli, italazimika kuunda "garland" kama hiyo: Jukumu na Kufunga Wajibu.
Kwa bahati mbaya, Helm haitakufanyia hivi. Wewe au msimamizi wako wa nguzo ya Kubernetes mnahitaji kutayarisha seti ya Majukumu na RoleBindings kwa akaunti ya huduma mapema ili kupitisha Helm.
Swali linatokea - kuna tofauti gani kati ya Jukumu na ClusterRole? Tofauti ni kwamba ClusterRole inafanya kazi kwa nafasi zote za majina, tofauti na Majukumu ya kawaida na RoleBindings, ambayo hufanya kazi kwa nafasi maalum ya majina. Unaweza kusanidi sera za kundi zima na nafasi zote za majina, au kubinafsishwa kwa kila nafasi ya majina kibinafsi.
Inafaa kutaja kuwa RBAC inasuluhisha shida nyingine kubwa. Watu wengi wanalalamika kwamba Helm, kwa bahati mbaya, sio multitenancy (haungi mkono multitenancy). Ikiwa timu kadhaa hutumia kundi na kutumia Helm, kimsingi haiwezekani kusanidi sera na kupunguza ufikiaji wao ndani ya nguzo hii, kwa sababu kuna akaunti fulani ya huduma ambayo Helm inaendesha chini yake, na huunda rasilimali zote kwenye nguzo kutoka chini yake. , ambayo wakati mwingine haifai sana. Hii ni kweli - kama faili ya binary yenyewe, kama mchakato, Helm Tiller haina dhana ya multitenancy.
Walakini, kuna njia nzuri ambayo hukuruhusu kuendesha Tiller mara nyingi kwenye nguzo. Hakuna tatizo na hili, Tiller inaweza kuzinduliwa katika kila nafasi ya majina. Kwa hivyo, unaweza kutumia RBAC, Kubeconfig kama muktadha, na kupunguza ufikiaji wa Helm maalum.
Itaonekana hivi.
Kwa mfano, kuna Kubeconfigs mbili zilizo na muktadha wa timu tofauti (nafasi mbili za majina): Timu ya X ya timu ya ukuzaji na nguzo ya wasimamizi. Kundi la wasimamizi lina Tiller yake pana, ambayo iko katika nafasi ya majina ya mfumo wa Kube, akaunti ya juu ya huduma inayolingana. Na nafasi tofauti ya majina ya timu ya maendeleo, wataweza kupeleka huduma zao kwenye nafasi maalum ya majina.
Hii ni njia inayoweza kutekelezeka, Tiller haina njaa ya nguvu kiasi kwamba itaathiri sana bajeti yako. Hii ni mojawapo ya ufumbuzi wa haraka.
Jisikie huru kusanidi Tiller kando na kutoa Kubeconfig na muktadha wa timu, kwa msanidi maalum au kwa mazingira: Dev, Staging, Production (ina shaka kuwa kila kitu kitakuwa kwenye nguzo moja, hata hivyo, hii inaweza kufanywa).
Tukiendelea na hadithi yetu, hebu tubadilike kutoka kwa RBAC na tuzungumze kuhusu ConfigMaps.
ConfigMaps
Helm hutumia ConfigMaps kama hifadhi yake ya data. Tulipozungumza kuhusu usanifu, hapakuwa na hifadhidata popote ambayo ingehifadhi taarifa kuhusu matoleo, usanidi, urejeshaji nyuma, n.k. ConfigMaps inatumika kwa hili.
Tatizo kuu la ConfigMaps linajulikana - si salama kwa kanuni; haiwezekani kuhifadhi data nyeti. Tunazungumza juu ya kila kitu ambacho haipaswi kwenda zaidi ya huduma, kwa mfano, nywila. Njia asilia ya Helm hivi sasa ni kubadili kutoka kutumia ConfigMaps hadi kwa siri.
Hii inafanywa kwa urahisi sana. Batilisha mpangilio wa Tiller na ubainishe kuwa hifadhi itakuwa siri. Kisha kwa kila upelekaji utapokea sio ConfigMap, lakini siri.
Unaweza kusema kwamba siri yenyewe ni dhana ya ajabu na si salama sana. Walakini, inafaa kuelewa kuwa watengenezaji wa Kubernetes wenyewe wanafanya hivi. Kuanzia toleo la 1.10, i.e. Kwa muda mrefu sasa, imewezekana, angalau katika mawingu ya umma, kuunganisha hifadhi sahihi ili kuhifadhi siri. Timu sasa inashughulikia njia za kusambaza vyema ufikiaji wa siri, maganda ya mtu binafsi, au huluki zingine.
Ni bora kuhamisha Helm ya Hifadhi kwa siri, na wao, kwa upande wake, wanalindwa katikati.
Bila shaka itabaki kikomo cha kuhifadhi data cha MB 1. Helm hapa hutumia etcd kama hifadhi iliyosambazwa kwa ConfigMaps. Na huko walizingatia kuwa hii ilikuwa sehemu ya data inayofaa kwa replication, nk. Kuna majadiliano ya kuvutia juu ya hili kwenye Reddit, ninapendekeza kupata usomaji huu wa kuchekesha kwa wikendi au kusoma dondoo .
Repo za Chati
Chati ndizo zilizo hatarini zaidi kijamii na zinaweza kuwa chanzo cha "Mtu wa kati", haswa ikiwa unatumia suluhisho la hisa. Kwanza kabisa, tunazungumza juu ya hazina ambazo zimefichuliwa kupitia HTTP.
Hakika unahitaji kufichua Helm Repo juu ya HTTPS - hili ndilo chaguo bora na ni la gharama nafuu.
Makini na utaratibu wa saini ya chati. Teknolojia ni rahisi kama kuzimu. Hiki ndicho kitu unachotumia kwenye GitHub, mashine ya kawaida ya PGP iliyo na funguo za umma na za kibinafsi. Sanidi na uhakikishe, kuwa na funguo zinazohitajika na kusaini kila kitu, kwamba hii ni chati yako kweli.
Aidha, Helm mteja anatumia TLS (sio kwa maana ya HTTP ya upande wa seva, lakini TLS ya pande zote). Unaweza kutumia funguo za seva na mteja ili kuwasiliana. Kuwa mkweli, situmii utaratibu kama huo kwa sababu sipendi vyeti vya kuheshimiana. Kimsingi, - zana kuu ya kusanidi Helm Repo kwa Helm 2 - pia inasaidia uandishi wa kimsingi. Unaweza kutumia auth msingi ikiwa ni rahisi zaidi na tulivu.
Pia kuna programu-jalizi , ambayo hukuruhusu kupangisha Chati Repos kwenye Hifadhi ya Wingu la Google. Hii ni rahisi kabisa, inafanya kazi vizuri na ni salama kabisa, kwa sababu mifumo yote iliyoelezewa inasindika tena.
Ukiwezesha HTTPS au TLS, tumia mTLS, na kuwezesha auth msingi ili kupunguza zaidi hatari, utapata njia salama ya mawasiliano na Helm CLI na Chati Repo.
gRPC API
Hatua inayofuata ni muhimu sana - kupata Tiller, ambayo iko katika nguzo na ni, kwa upande mmoja, seva, kwa upande mwingine, yenyewe inapata vipengele vingine na inajaribu kujifanya kuwa mtu.
Kama nilivyokwisha sema, Tiller ni huduma inayofichua gRPC, mteja wa Helm huijia kupitia gRPC. Kwa chaguo-msingi, bila shaka, TLS imezimwa. Kwa nini hii ilifanyika ni swali linaloweza kujadiliwa, inaonekana kwangu kurahisisha usanidi mwanzoni.
Kwa uzalishaji na hata uwekaji hatua, ninapendekeza kuwezesha TLS kwenye gRPC.
Kwa maoni yangu, tofauti na mTLS kwa chati, hii inafaa hapa na inafanywa kwa urahisi sana - toa miundombinu ya PQI, unda cheti, uzindua Tiller, uhamishe cheti wakati wa kuanzishwa. Baada ya hayo, unaweza kutekeleza amri zote za Helm, ukijiwasilisha na cheti kilichozalishwa na ufunguo wa kibinafsi.
Kwa njia hii utajikinga na maombi yote kwa Tiller kutoka nje ya nguzo.
Kwa hivyo, tumelinda kituo cha uunganisho kwa Tiller, tayari tumejadili RBAC na kurekebisha haki za apiserver ya Kubernetes, kupunguza kikoa ambacho kinaweza kuingiliana.
Helm iliyolindwa
Hebu tuangalie mchoro wa mwisho. Ni usanifu sawa na mishale sawa.
Viunganisho vyote sasa vinaweza kuchorwa kwa kijani kibichi kwa usalama:
- kwa Chati Repo tunatumia TLS au mTLS na auth msingi;
- mTLS kwa Tiller, na inafichuliwa kama huduma ya gRPC na TLS, tunatumia vyeti;
- nguzo hutumia akaunti maalum ya huduma iliyo na Role na RoleBinding.
Tumelinda nguzo hiyo kwa kiasi kikubwa, lakini mtu mwerevu alisema:
"Kunaweza kuwa na suluhisho moja tu salama kabisa - kompyuta iliyozimwa, ambayo iko kwenye sanduku la zege na inalindwa na askari."
Kuna njia tofauti za kudhibiti data na kupata vekta mpya za shambulio. Hata hivyo, nina imani kwamba mapendekezo haya yatafikia kiwango cha msingi cha usalama cha sekta hiyo.
Bonasi
Sehemu hii haihusiani moja kwa moja na usalama, lakini pia itakuwa muhimu. Nitakuonyesha mambo ya kuvutia ambayo watu wachache wanajua kuyahusu. Kwa mfano, jinsi ya kutafuta chati - rasmi na isiyo rasmi.
Katika hazina Sasa kuna chati takriban 300 na mito miwili: imara na incubator. Mtu yeyote anayechangia anajua vizuri jinsi ilivyo vigumu kupata kutoka kwa incubator hadi imara, na jinsi ilivyo rahisi kuruka nje ya utulivu. Walakini, hii sio zana bora ya kutafuta chati za Prometheus na chochote kingine unachopenda, kwa sababu moja rahisi - sio portal ambapo unaweza kutafuta vifurushi kwa urahisi.
Lakini kuna huduma , ambayo inafanya iwe rahisi zaidi kupata chati. Muhimu zaidi, kuna hazina nyingi zaidi za nje na karibu hirizi 800 zinapatikana. Pia, unaweza kuunganisha hazina yako ikiwa kwa sababu fulani hutaki kutuma chati zako kwa utulivu.
Jaribu hub.helm.sh na tuiendeleze pamoja. Huduma hii iko chini ya mradi wa Helm, na unaweza hata kuchangia kwa UI yake ikiwa wewe ni msanidi programu wa mbele na unataka tu kuboresha mwonekano.
Ningependa pia kuteka mawazo yako Fungua muunganisho wa API ya Wakala wa Huduma. Inaonekana kuwa ngumu na isiyo wazi, lakini inasuluhisha shida ambazo kila mtu anakabiliwa nazo. Acha nieleze kwa mfano rahisi.
Kuna kundi la Kubernetes ambalo tunataka kuendesha programu ya kawaida - WordPress. Kwa ujumla, hifadhidata inahitajika kwa utendakazi kamili. Kuna suluhisho nyingi tofauti, kwa mfano, unaweza kuzindua huduma yako ya hali ya juu. Hii sio rahisi sana, lakini watu wengi hufanya hivyo.
Wengine, kama sisi katika Chainstack, hutumia hifadhidata zinazodhibitiwa kama MySQL au PostgreSQL kwa seva zao. Ndiyo sababu hifadhidata zetu ziko mahali fulani kwenye wingu.
Lakini tatizo linatokea: tunahitaji kuunganisha huduma yetu na hifadhidata, kuunda ladha ya hifadhidata, kuhamisha kitambulisho na kwa namna fulani kuisimamia. Yote hii kawaida hufanywa kwa mikono na msimamizi wa mfumo au msanidi programu. Na hakuna shida wakati kuna programu chache. Wakati kuna mengi yao, unahitaji kuchanganya. Kuna mvunaji kama huyo - ni Dalali wa Huduma. Inakuruhusu kutumia programu-jalizi maalum kwa kundi la wingu la umma na kuagiza rasilimali kutoka kwa mtoa huduma kupitia Broker, kana kwamba ni API. Ili kufanya hivyo, unaweza kutumia zana za asili za Kubernetes.
Ni rahisi sana. Unaweza kuuliza, kwa mfano, Usimamizi wa MySQL huko Azure na kiwango cha msingi (hii inaweza kusanidiwa). Kwa kutumia API ya Azure, hifadhidata itaundwa na kutayarishwa kwa matumizi. Huna haja ya kuingilia kati na hili, programu-jalizi inawajibika kwa hili. Kwa mfano, OSBA (programu-jalizi ya Azure) itarudisha kitambulisho kwa huduma na kuipitisha kwa Helm. Utaweza kutumia WordPress na MySQL ya wingu, usishughulikie hifadhidata zinazosimamiwa hata kidogo na usijali kuhusu huduma za hali ya juu ndani.
Tunaweza kusema kwamba Helm hufanya kama gundi ambayo, kwa upande mmoja, inakuwezesha kupeleka huduma, na kwa upande mwingine, hutumia rasilimali za watoa huduma za wingu.
Unaweza kuandika programu-jalizi yako mwenyewe na utumie hadithi hii yote kwenye msingi. Kisha utakuwa na programu-jalizi yako mwenyewe kwa mtoaji wa ushirika wa Wingu. Ninapendekeza kujaribu mbinu hii, haswa ikiwa una kiwango kikubwa na unataka kupeleka kwa haraka dev, staging, au miundombinu yote ya kipengele. Hii itarahisisha maisha kwa shughuli zako au DevOps.
Ugunduzi mwingine ambao tayari nimeutaja ni helm-gcs programu-jalizi, ambayo hukuruhusu kutumia ndoo za Google (hifadhi ya kitu) kuhifadhi chati za Helm.
Unahitaji tu amri nne ili kuanza kuitumia:
- kufunga Plugin;
- kuianzisha;
- weka njia ya ndoo, ambayo iko kwenye gcp;
- kuchapisha chati kwa njia ya kawaida.
Uzuri ni kwamba njia ya asili ya gcp itatumika kwa idhini. Unaweza kutumia akaunti ya huduma, akaunti ya msanidi programu, chochote unachotaka. Ni rahisi sana na haigharimu chochote kufanya kazi. Ikiwa wewe, kama mimi, unakuza falsafa isiyo na maana, basi hii itakuwa rahisi sana, haswa kwa timu ndogo.
Njia mbadala
Helm sio suluhisho pekee la usimamizi wa huduma. Kuna maswali mengi juu yake, ambayo labda ndiyo sababu toleo la tatu lilionekana haraka sana. Bila shaka kuna njia mbadala.
Hizi zinaweza kuwa suluhisho maalum, kwa mfano, Ksonnet au Metaparticle. Unaweza kutumia zana zako za kawaida za usimamizi wa miundombinu (Ansible, Terraform, Chef, n.k.) kwa madhumuni yale yale niliyozungumzia.
Hatimaye kuna suluhisho , ambaye umaarufu wake unakua.
Mfumo wa Opereta ndio njia mbadala ya juu ya Helm ya kuzingatia.
Ni asili zaidi ya CNCF na Kubernetes, lakini kizuizi cha kuingia ni kikubwa zaidi, unahitaji kupanga zaidi na kuelezea maonyesho kidogo.
Kuna nyongeza mbalimbali, kama vile Rasimu, Kiunzi. Hurahisisha maisha, kwa mfano, hurahisisha mzunguko wa kutuma na kuzindua Helm kwa wasanidi programu kupeleka mazingira ya majaribio. Ningewaita wawezeshaji.
Hapa kuna chati ya kuona ya mahali kila kitu kiko.
Kwenye mhimili wa x kuna kiwango cha udhibiti wako wa kibinafsi juu ya kile kinachotokea, kwenye mhimili wa y ni kiwango cha asili cha Kubernetes. Helm version 2 huanguka mahali fulani katikati. Katika toleo la 3, sio kubwa sana, lakini udhibiti na kiwango cha asili kimeboreshwa. Suluhisho katika kiwango cha Ksonnet bado ni duni hata kwa Helm 2. Hata hivyo, wanafaa kuangalia ili kujua ni nini kingine katika ulimwengu huu. Bila shaka, kidhibiti chako cha usanidi kitakuwa chini ya udhibiti wako, lakini si asili ya Kubernetes.
Mfumo wa Opereta ni asili ya Kubernetes na hukuruhusu kuudhibiti kwa umaridadi na uangalifu zaidi (lakini kumbuka kuhusu kiwango cha kuingia). Badala yake, hii inafaa kwa programu maalum na uundaji wa usimamizi kwa ajili yake, badala ya kivunaji kikubwa cha kufunga idadi kubwa ya programu kwa kutumia Helm.
Wakuzaji huboresha udhibiti kidogo, kutimiza utendakazi, au kukata pembe kwenye mabomba ya CI/CD.
Wakati ujao wa Helm
Habari njema ni kwamba Helm 3 inakuja. Toleo la alpha la Helm 3.0.0-alpha.2 tayari limetolewa, unaweza kulijaribu. Ni thabiti kabisa, lakini utendakazi bado ni mdogo.
Kwa nini unahitaji Helm 3? Kwanza kabisa, hii ni hadithi kuhusu kutoweka kwa Tiller, kama sehemu. Hii, kama unavyoelewa tayari, ni hatua kubwa mbele, kwa sababu kutoka kwa mtazamo wa usalama wa usanifu, kila kitu kimerahisishwa.
Wakati Helm 2 iliundwa, ambayo ilikuwa karibu na wakati wa Kubernetes 1.8 au hata mapema, dhana nyingi zilikuwa changa. Kwa mfano, dhana ya CRD sasa inatekelezwa kikamilifu, na Helm itatekelezwa tumia CRDkuhifadhi miundo. Itawezekana kutumia mteja tu na sio kudumisha sehemu ya seva. Ipasavyo, tumia amri asili za Kubernetes kufanya kazi na miundo na rasilimali. Hii ni hatua kubwa mbele.
Itaonekana msaada kwa hazina asili za OCI (Open Container Initiative). Huu ni mpango mkubwa, na Helm inavutiwa hasa ili kuchapisha chati zake. Inakuja kwa uhakika kwamba, kwa mfano, Docker Hub inasaidia viwango vingi vya OCI. Sidhani, lakini labda watoa huduma wa hazina wa Docker wataanza kukupa fursa ya kukaribisha chati zao za Helm.
Hadithi yenye utata kwangu ni Msaada wa Lua, kama injini ya kuiga maandishi ya maandishi. Mimi si shabiki mkubwa wa Lua, lakini hii itakuwa kipengele cha hiari kabisa. Niliangalia hii mara 3 - kutumia Lua haitakuwa muhimu. Kwa hivyo, wale wanaotaka kuweza kutumia Lua, wale wanaopenda Go, wajiunge na kambi yetu kubwa na watumie go-tmpl kwa hili.
Hatimaye, nilichokuwa nikikosa hakika kilikuwa kuibuka kwa schema na uthibitishaji wa aina ya data. Hakutakuwa na shida zaidi na int au kamba, hakuna haja ya kufunika sifuri kwa nukuu mbili. Schema ya JSONS itaonekana ambayo itakuruhusu kuelezea hii kwa maadili.
Itafanyiwa kazi upya sana mfano unaoendeshwa na tukio. Tayari imeelezwa kimawazo. Angalia tawi la Helm 3, na utaona ni matukio ngapi na ndoano na vitu vingine vimeongezwa, ambavyo vitarahisisha sana na, kwa upande mwingine, kuongeza udhibiti wa michakato ya kupeleka na athari kwao.
Helm 3 itakuwa rahisi, salama, na ya kufurahisha zaidi, sio kwa sababu hatupendi Helm 2, lakini kwa sababu Kubernetes inakua zaidi. Ipasavyo, Helm inaweza kutumia maendeleo ya Kubernetes na kuunda wasimamizi bora wa Kubernetes juu yake.
Habari nyingine njema ni hiyo Alexander Khayorov atakuambia, Hebu tukumbushe kwamba mkutano juu ya ushirikiano wa michakato ya maendeleo, kupima na uendeshaji utafanyika Moscow Septemba 30 na Oktoba 1. Bado unaweza kuifanya hadi tarehe 20 Agosti na utuambie kuhusu uzoefu wako na suluhisho kazi za mbinu ya DevOps.
Fuata vituo vya ukaguzi vya mkutano na habari kwenye ΠΈ .
Chanzo: mapenzi.com