Kuanzisha Helm 3

Kumbuka. tafsiri.: Mei 16 mwaka huu ni hatua muhimu katika maendeleo ya meneja wa kifurushi cha Kubernetes - Helm. Siku hii, toleo la kwanza la alpha la toleo kuu la baadaye la mradi - 3.0 - liliwasilishwa. Kutolewa kwake kutaleta mabadiliko makubwa na yaliyosubiriwa kwa muda mrefu kwa Helm, ambayo wengi katika jumuiya ya Kubernetes wana matumaini makubwa. Sisi wenyewe ni mojawapo ya haya, kwa kuwa tunatumia Helm kikamilifu kwa kupeleka maombi: tumeiunganisha kwenye zana yetu ya kutekeleza CI/CD. werf na mara kwa mara tunatoa mchango wetu katika maendeleo ya mto. Tafsiri hii inachanganya maelezo 7 kutoka kwa blogu rasmi ya Helm, ambayo imetolewa kwa toleo la kwanza la alpha la Helm 3 na inazungumza kuhusu historia ya mradi na vipengele vikuu vya Helm 3. Mwandishi wao ni Matt "bacongobbler" Fisher, mfanyakazi wa Microsoft. na mmoja wa wasimamizi wakuu wa Helm.

Mnamo Oktoba 15, 2015, mradi ambao sasa unajulikana kama Helm ulizaliwa. Mwaka mmoja tu baada ya kuanzishwa kwake, jumuiya ya Helm ilijiunga na Kubernetes, huku ikifanya kazi kwa bidii kwenye Helm 2. Mnamo Juni 2018, Helm. alijiunga na CNCF kama mradi unaoendelea (wa incubating). Mbele ya sasa hivi, na toleo la kwanza la alfa la Helm 3 mpya liko njiani. (toleo hili tayari imefanyika katikati ya Mei - takriban. tafsiri.).

Katika makala haya, nitazungumza kuhusu mahali ambapo yote yalianzia, jinsi tulivyofika hapa tulipo leo, kutambulisha baadhi ya vipengele vya kipekee vinavyopatikana katika toleo la kwanza la alfa la Helm 3, na kueleza jinsi tunavyopanga kuendeleza zaidi.

Muhtasari:

• historia ya uumbaji wa Helm;
• kwaheri ya zabuni kwa Tiller;
• hazina za chati;
• usimamizi wa kutolewa;
• mabadiliko katika utegemezi wa chati;
• chati za maktaba;
• nini kinafuata?

Historia ya Helm

Kuzaliwa

Helm 1 ilianza kama mradi wa Open Source iliyoundwa na Deis. Tulikuwa mwanzo mdogo kufyonzwa Microsoft katika spring 2017. Mradi wetu mwingine wa Open Source, unaoitwa pia Deis, ulikuwa na zana deisctl, ambayo ilitumika (miongoni mwa mambo mengine) kusakinisha na kuendesha jukwaa la Deis Kundi la meli. Wakati huo, Fleet ilikuwa mojawapo ya majukwaa ya kwanza ya kuandaa vyombo.

Katikati ya 2015, tuliamua kubadilisha mkondo na kuhamisha Deis (wakati huo iliitwa Deis Workflow) kutoka Fleet hadi Kubernetes. Moja ya kwanza kuwa upya ilikuwa chombo cha ufungaji. deisctl. Tuliitumia kusakinisha na kudhibiti mtiririko wa kazi wa Deis katika kundi la Fleet.

Helm 1 iliundwa kwa mfano wa wasimamizi maarufu wa vifurushi kama vile Homebrew, apt na yum. Lengo lake kuu lilikuwa kurahisisha kazi kama vile kufunga na kusakinisha programu kwenye Kubernetes. Helm ilianzishwa rasmi mnamo 2015 katika mkutano wa KubeCon huko San Francisco.

Jaribio letu la kwanza na Helm lilifanya kazi, lakini haikuwa bila mapungufu makubwa. Alichukua seti ya maonyesho ya Kubernetes, yaliyowekwa ladha ya jenereta kama vitalu vya utangulizi vya YAML. (jambo la mbele)*, na kupakia matokeo katika Kubernetes.

* Kumbuka. tafsiri.: Kutoka kwa toleo la kwanza la Helm, sintaksia ya YAML ilichaguliwa kuelezea rasilimali za Kubernetes, na violezo vya Jinja na hati za Python zilitumika wakati wa kuandika usanidi. Tuliandika zaidi kuhusu hili na muundo wa toleo la kwanza la Helm kwa ujumla katika sura "Historia Fupi ya Helm" nyenzo hii.

Kwa mfano, ili kubadilisha sehemu katika faili ya YAML, ilibidi uongeze muundo ufuatao kwenye faili ya maelezo:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

Ni vizuri kwamba injini za template zipo leo, sivyo?

Kwa sababu nyingi, kisakinishi hiki cha mapema cha Kubernetes kilihitaji orodha yenye msimbo mgumu wa faili za maelezo na kutekeleza tu mfuatano mdogo, usiobadilika wa matukio. Ilikuwa ngumu sana kutumia hivi kwamba timu ya Deis Workflow R&D ilikuwa na wakati mgumu ilipojaribu kuhamisha bidhaa zao kwenye jukwaa hili - hata hivyo, mbegu za wazo hilo zilikuwa tayari zimepandwa. Jaribio letu la kwanza lilikuwa fursa nzuri ya kujifunza: tuligundua kuwa tulikuwa na shauku ya kweli ya kuunda zana za pragmatiki ambazo hutatua matatizo ya kila siku kwa watumiaji wetu.

Kulingana na uzoefu wa makosa ya zamani, tulianza kutengeneza Helm 2.

Kutengeneza Helm 2

Mwishoni mwa 2015, timu ya Google iliwasiliana nasi. Walikuwa wakifanya kazi kwenye zana kama hiyo ya Kubernetes. Kidhibiti Usambazaji cha Kubernetes kilikuwa ni lango la zana iliyopo ambayo ilitumika kwa Google Cloud Platform. “Je, tungependa,” wakauliza, “kutumia siku chache kuzungumzia mambo yanayofanana na yanayotofautiana?”

Mnamo Januari 2016, timu za Helm na Meneja Usambazaji zilikutana Seattle kubadilishana mawazo. Mazungumzo yalimalizika kwa mpango kabambe: kuchanganya miradi yote miwili kuunda Helm 2. Pamoja na Deis na Google, vijana kutoka SkippBox (sasa ni sehemu ya Bitnami - takriban. transl.), na tukaanza kufanya kazi kwenye Helm 2.

Tulitaka kuweka urahisi wa matumizi ya Helm, lakini ongeza yafuatayo:

• violezo vya chati kwa ubinafsishaji;
• usimamizi wa ndani ya nguzo kwa timu;
• hazina ya chati ya kiwango cha kimataifa;
• muundo wa kifurushi thabiti na chaguo la saini;
• kujitolea dhabiti kwa uchapishaji wa kisemantiki na kudumisha utangamano wa nyuma kati ya matoleo.

Ili kufikia malengo haya, kipengele cha pili kimeongezwa kwenye mfumo ikolojia wa Helm. Sehemu hii ya ndani ya nguzo iliitwa Tiller na iliwajibika kusakinisha chati za Helm na kuzisimamia.

Tangu kutolewa kwa Helm 2 mnamo 2016, Kubernetes imeongeza uvumbuzi kadhaa kuu. Udhibiti wa ufikiaji unaotegemea jukumu (RBAC), ambayo hatimaye ilibadilisha Udhibiti wa Ufikiaji wa Sifa (ABAC). Aina mpya za rasilimali zilianzishwa (Usambazaji ulikuwa bado kwenye beta wakati huo). Ufafanuzi wa Rasilimali Maalum (hapo awali uliitwa Rasilimali za Watu wa Tatu au TPRs) ulibuniwa. Na muhimu zaidi, seti ya mazoea bora imeibuka.

Katikati ya mabadiliko haya yote, Helm iliendelea kuwatumikia watumiaji wa Kubernetes kwa uaminifu. Baada ya miaka mitatu na nyongeza nyingi mpya, ilikuwa wazi kwamba ilikuwa ni wakati wa kufanya mabadiliko makubwa kwa codebase ili kuhakikisha Helm inaweza kuendelea kukidhi mahitaji yanayokua ya mfumo wa ikolojia unaoendelea.

Kwaheri ya zabuni kwa Tiller

Wakati wa kuunda Helm 2, tulianzisha Tiller kama sehemu ya ushirikiano wetu na Kidhibiti Usambazaji cha Google. Tiller ilichukua jukumu muhimu kwa timu zinazofanya kazi ndani ya kundi moja: iliruhusu wataalamu tofauti wanaoendesha miundombinu kuingiliana na seti sawa za matoleo.

Kwa kuwa udhibiti wa ufikiaji wa msingi wa jukumu (RBAC) uliwezeshwa kwa chaguo-msingi katika Kubernetes 1.6, kufanya kazi na Tiller katika uzalishaji kulikua vigumu zaidi. Kwa sababu ya idadi kubwa ya sera zinazowezekana za usalama, msimamo wetu umekuwa kutoa usanidi unaoruhusu kwa chaguo-msingi. Hii iliruhusu wanaoanza kufanya majaribio ya Helm na Kubernetes bila kulazimika kuingia kwenye mipangilio ya usalama kwanza. Kwa bahati mbaya, usanidi huu wa ruhusa unaweza kumpa mtumiaji aina mbalimbali za ruhusa ambazo hakuhitaji. Wahandisi wa DevOps na SRE walilazimika kujifunza hatua za ziada za uendeshaji wakati wa kusakinisha Tiller katika kundi la wapangaji wengi.

Baada ya kujifunza jinsi jumuiya ilivyotumia Helm katika hali mahususi, tuligundua kuwa mfumo wa usimamizi wa uchapishaji wa Tiller haukuhitaji kutegemea kijenzi cha ndani ya nguzo ili kudumisha hali au utendakazi kama kitovu kikuu cha taarifa ya kutolewa. Badala yake, tunaweza kupokea taarifa kutoka kwa seva ya Kubernetes API, kutengeneza chati kwa upande wa mteja, na kuhifadhi rekodi ya usakinishaji katika Kubernetes.

Lengo kuu la Tiller lingeweza kufikiwa bila Tiller, kwa hivyo moja ya maamuzi yetu ya kwanza kuhusu Helm 3 ilikuwa kuachana kabisa na Tiller.

Tiller akiwa ameondoka, mtindo wa usalama wa Helm umerahisishwa kwa kiasi kikubwa. Helm 3 sasa inaauni mbinu zote za kisasa za usalama, utambulisho, na uidhinishaji wa Kubernetes ya sasa. Ruhusa za usukani huamuliwa kutumia kubeconfig faili. Wasimamizi wa nguzo wanaweza kuzuia haki za mtumiaji kwa kiwango chochote cha uzito. Matoleo bado yanahifadhiwa ndani ya nguzo, na utendakazi mwingine wa Helm unasalia kuwa sawa.

Hifadhi za chati

Katika kiwango cha juu, hazina ya chati ni mahali ambapo chati zinaweza kuhifadhiwa na kushirikiwa. Kiteja cha Helm hupakia na kutuma chati kwenye hazina. Kwa ufupi, hazina ya chati ni seva ya awali ya HTTP yenye faili ya index.yaml na baadhi ya chati zilizopakiwa.

Ingawa kuna manufaa fulani kwa API ya Chati Repository kukidhi mahitaji ya msingi ya hifadhi, pia kuna hasara chache:

• Hazina za chati hazioani na utekelezaji mwingi wa usalama unaohitajika katika mazingira ya uzalishaji. Kuwa na API ya kawaida ya uthibitishaji na uidhinishaji ni muhimu sana katika hali za uzalishaji.
• Zana za asili za chati ya Helm, zinazotumiwa kutia sahihi, kuthibitisha uadilifu na asili ya chati, ni sehemu ya hiari ya mchakato wa uchapishaji wa Chati.
• Katika hali za watumiaji wengi, chati sawa inaweza kupakiwa na mtumiaji mwingine, na kuongeza mara mbili ya nafasi inayohitajika ili kuhifadhi maudhui sawa. Hifadhi nadhifu zimetengenezwa ili kutatua tatizo hili, lakini si sehemu ya vipimo rasmi.
• Kutumia faili moja ya faharasa kutafuta, kuhifadhi metadata, na kurejesha chati kumefanya iwe vigumu kutengeneza utekelezaji salama wa watumiaji wengi.

Mradi Usambazaji wa Docker (pia inajulikana kama Usajili wa Docker v2) ndiye mrithi wa Usajili wa Docker na kimsingi hufanya kama seti ya zana za upakiaji, usafirishaji, uhifadhi na uwasilishaji wa picha za Docker. Huduma nyingi kubwa za wingu hutoa bidhaa zinazotegemea Usambazaji. Shukrani kwa umakini huu ulioongezeka, mradi wa Usambazaji umenufaika kutokana na maboresho ya miaka mingi, mbinu bora za usalama, na majaribio ya uwanjani ambayo yameufanya kuwa mmoja wa mashujaa ambao hawajaimbwa wa ulimwengu wa Open Source.

Lakini je, unajua kwamba Mradi wa Usambazaji uliundwa ili kusambaza aina yoyote ya maudhui, si tu picha za makontena?

Shukrani kwa juhudi Fungua Mpango wa Kontena (au OCI), Chati za Helm zinaweza kuwekwa kwenye tukio lolote la Usambazaji. Kwa sasa, mchakato huu ni wa majaribio. Usaidizi wa kuingia katika akaunti na vipengele vingine vinavyohitajika kwa Helm 3 kamili ni kazi inayoendelea, lakini tunafurahi kujifunza kutokana na uvumbuzi ambao timu za OCI na Usambazaji zimefanya kwa miaka mingi. Na kupitia ushauri na mwongozo wao, tunajifunza jinsi inavyokuwa kuendesha huduma inayopatikana kwa kiwango kikubwa.

Maelezo ya kina zaidi ya baadhi ya mabadiliko yanayokuja kwenye hazina za chati ya Helm yanapatikana по ссылке.

Usimamizi wa kutolewa

Katika Helm 3, hali ya maombi inafuatiliwa ndani ya nguzo na jozi ya vitu:

• kitu cha kutolewa - inawakilisha mfano wa maombi;
• toleo la siri - inawakilisha hali inayotakiwa ya programu kwa wakati maalum (kwa mfano, kutolewa kwa toleo jipya).

Changamoto helm install huunda kitu cha kutolewa na toleo la siri. Wito helm upgrade inahitaji kitu cha kutolewa (ambacho kinaweza kubadilisha) na kuunda toleo jipya la siri lililo na thamani mpya na faili ya maelezo iliyotayarishwa.

Kitu cha toleo kina maelezo kuhusu toleo, ambapo toleo ni usakinishaji mahususi wa chati na thamani zilizotajwa. Kipengee hiki kinafafanua metadata ya kiwango cha juu kuhusu toleo. Kitu cha kutolewa kinaendelea katika kipindi chote cha maisha ya programu na ndiye mmiliki wa siri zote za toleo la toleo, pamoja na vitu vyote vilivyoundwa moja kwa moja na chati ya Helm.

Siri ya toleo la toleo huhusisha toleo na mfululizo wa masahihisho (usakinishaji, masasisho, urejeshaji nyuma, ufutaji).

Katika Helm 2, masahihisho yalikuwa thabiti sana. Wito helm install imeundwa v1, sasisho linalofuata (sasisha) - v2, na kadhalika. Siri ya toleo na toleo limekunjwa na kuwa kitu kimoja kinachojulikana kama marekebisho. Marekebisho yalihifadhiwa katika nafasi ya majina sawa na Tiller, ambayo ilimaanisha kuwa kila toleo lilikuwa la "kimataifa" kulingana na nafasi ya majina; kama matokeo, mfano mmoja tu wa jina unaweza kutumika.

Katika Helm 3, kila toleo linahusishwa na siri ya toleo moja au zaidi. Kitu cha kutolewa kila wakati kinaelezea toleo la sasa lililotumwa kwa Kubernetes. Siri ya kila toleo la toleo hufafanua toleo moja tu la toleo hilo. Uboreshaji, kwa mfano, utaunda toleo jipya la siri na kisha kubadilisha kifaa cha kutolewa ili kuelekeza kwenye toleo hilo jipya. Katika kesi ya kurejesha, unaweza kutumia siri za toleo la awali kurudisha toleo katika hali ya awali.

Baada ya Tiller kuachwa, Helm 3 huhifadhi data iliyotolewa katika nafasi ya majina sawa na toleo. Mabadiliko haya hukuruhusu kusakinisha chati iliyo na jina sawa la toleo katika nafasi tofauti ya majina, na data huhifadhiwa kati ya masasisho ya vikundi/kuwashwa upya n.k. Kwa mfano, unaweza kusakinisha WordPress kwenye nafasi ya majina ya "foo" na kisha kwenye nafasi ya majina ya "bar", na matoleo yote mawili yanaweza kuitwa "wordpress".

Mabadiliko ya vitegemezi vya chati

Chati zimefungwa (kwa kutumia helm package) kwa ajili ya matumizi na Helm 2 inaweza kusakinishwa na Helm 3, hata hivyo utendakazi wa ukuzaji wa chati umerekebishwa kabisa, kwa hivyo baadhi ya mabadiliko lazima yafanywe ili kuendeleza uundaji wa chati kwa Helm 3. Hasa, mfumo wa usimamizi wa utegemezi wa chati umebadilika.

Mfumo wa usimamizi wa utegemezi wa chati umehama kutoka requirements.yaml и requirements.lock juu ya Chart.yaml и Chart.lock. Hii ina maana kwamba chati zilizotumia amri helm dependency, zinahitaji usanidi fulani ili kufanya kazi katika Helm 3.

Hebu tuangalie mfano. Hebu tuongeze utegemezi kwenye chati katika Helm 2 na tuone mabadiliko gani tunapohamia kwenye Helm 3.

Katika Helm 2 requirements.yaml ilionekana kama hii:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Katika Helm 3, utegemezi sawa utaonyeshwa kwako Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

Chati bado zinapakuliwa na kuwekwa kwenye saraka charts/, kwa hivyo chati ndogo (chati ndogo), iliyoko kwenye orodha charts/, itaendelea kufanya kazi bila mabadiliko.

Tunakuletea Chati za Maktaba

Helm 3 inasaidia darasa la chati zinazoitwa chati za maktaba (chati ya maktaba). Chati hii inatumiwa na chati zingine, lakini haiundi vizalia vya programu yoyote yenyewe. Violezo vya chati za maktaba vinaweza tu kutangaza vipengele define. Maudhui mengine hupuuzwa tu. Hii inaruhusu watumiaji kutumia tena na kushiriki vijisehemu vya msimbo vinavyoweza kutumika kwenye chati nyingi, hivyo basi kuepuka kurudia na kutii kanuni. DRY.

Chati za maktaba zimetangazwa katika sehemu hiyo dependencies katika faili Chart.yaml. Kuzisakinisha na kuzisimamia sio tofauti na chati zingine.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

Tumefurahishwa na hali za utumiaji ambazo kipengele hiki kitafungua kwa wasanidi wa chati, na pia mbinu bora zinazoweza kujitokeza kutoka kwa chati za maktaba.

Nini hapo?

Helm 3.0.0-alpha.1 ndio msingi ambao tunaanza kuunda toleo jipya la Helm. Katika makala niliyoelezea baadhi ya vipengele vya kuvutia vya Helm 3. Wengi wao bado wako katika hatua za mwanzo za maendeleo na hii ni ya kawaida; Lengo la toleo la alpha ni kujaribu wazo, kukusanya maoni kutoka kwa watumiaji wa mapema, na kuthibitisha mawazo yetu.

Mara tu toleo la alpha linatolewa (kumbuka kuwa hii ni tayari imetokea - takriban. tafsiri.), tutaanza kukubali viraka vya Helm 3 kutoka kwa jumuiya. Unahitaji kuunda msingi thabiti ambao unaruhusu utendakazi mpya kuendelezwa na kupitishwa, na kwa watumiaji kuhisi kuhusika katika mchakato kwa kufungua tiketi na kufanya marekebisho.

Nimejaribu kuangazia baadhi ya maboresho makubwa yanayokuja kwenye Helm 3, lakini orodha hii sio kamilifu. Ramani kamili ya Helm 3 inajumuisha vipengele kama vile mikakati iliyoboreshwa ya kusasisha, ushirikiano wa kina na sajili za OCI, na matumizi ya miundo ya JSON ili kuthibitisha thamani za chati. Pia tunapanga kusafisha msingi wa msimbo na kusasisha sehemu zake ambazo zimepuuzwa kwa miaka mitatu iliyopita.

Ikiwa unahisi kama tumekosa kitu, tungependa kusikia mawazo yako!

Jiunge na mjadala wetu Vituo hafifu:

• #helm-users kwa maswali na mawasiliano rahisi na jamii;
• #helm-dev kujadili maombi ya kuvuta, kanuni na mende.

Unaweza pia kupiga gumzo katika Simu zetu za kila wiki za Wasanidi Programu wa Umma siku ya Alhamisi saa 19:30 MSK. Mikutano imejitolea kujadili masuala ambayo wasanidi programu wakuu na jumuiya wanafanyia kazi, pamoja na mada za majadiliano ya wiki. Mtu yeyote anaweza kujiunga na kushiriki katika mkutano. Kiungo kinapatikana katika kituo cha Slack #helm-dev.

PS kutoka kwa mtafsiri

Soma pia kwenye blogi yetu:

• «Meneja wa kifurushi cha Kubernetes - Helm: zamani, sasa, siku zijazo";
• «Kuangalia kwa kiasi kwenye Helm 2: "Hivi ndivyo ilivyo ..."";
• «Utangulizi wa vitendo kwa msimamizi wa kifurushi cha Kubernetes - Helm";
• «Vidokezo na mbinu za Kubernetes: kuhamisha rasilimali zinazoendeshwa katika kundi hadi kwa usimamizi wa Helm 2";
• «Fanya mazoezi na dapp. Sehemu ya 2. Kupeleka picha za Docker kwa Kubernetes kwa kutumia Helm'.

Chanzo: mapenzi.com