🥇3-njia unganisha kwenye werf: kupelekwa Kubernetes na Helm "kwenye steroids"

Kile ambacho sisi (na sio sisi tu) tumekuwa tukingojea kwa muda mrefu kimetokea: werf, shirika letu la programu huria la kuunda programu na kuziwasilisha kwa Kubernetes, sasa linaauni uwekaji mabadiliko kwa kutumia viraka vya kuunganisha njia 3! Zaidi ya hayo, sasa inawezekana kupitisha rasilimali zilizopo za K8s kwenye matoleo ya Helm bila kuziunda upya.

Kwa kifupi, tunaweka WERF_THREE_WAY_MERGE=enabled - tunapata kupelekwa "kama ndani kubectl apply", inaendana na usakinishaji uliopo wa Helm 2 na hata kidogo zaidi.

Lakini wacha tuanze na nadharia: ni vipi viraka vya njia-3, ni vipi watu walikuja na mbinu ya kuzizalisha, na kwa nini ni muhimu katika michakato ya CI/CD na miundombinu inayotegemea Kubernetes? Baada ya hapo, tutaangalia ni nini 3-way-merge iko kwenye werf, ni aina gani zinazotumiwa na chaguo-msingi, na jinsi ya kuidhibiti.

Je, kiraka cha kuunganisha kwa njia 3 ni nini?

Kwa hivyo, hebu tuanze na kazi ya kusambaza rasilimali zilizofafanuliwa katika YAML kwa Kubernetes.

API ya Kubernetes inatoa shughuli za kimsingi zifuatazo za kufanya kazi na rasilimali: kuunda, kurekebisha, kubadilisha na kufuta. Hizi zinakusudiwa kutumiwa kuunda utoaji rahisi wa rasilimali kwa nguzo. Jinsi gani?

Amri za lazima za kubectl

Mbinu ya kwanza ya kudhibiti vitu katika Kubernetes ni kutumia amri za lazima za kubectl kuunda, kurekebisha, na kufuta vitu hivi. Kwa ufupi:

timu kubectl run Unaweza kuendesha Upelekaji au Kazi:

kubectl run --generator=deployment/apps.v1 DEPLOYMENT_NAME --image=IMAGE

timu kubectl scale - Badilisha idadi ya nakala:
```
kubectl scale --replicas=3 deployment/mysql
```
nk

Njia hii inaweza kuonekana kuwa rahisi kwa mtazamo wa kwanza. Walakini, kuna shida:

Ni ngumu kwake automatiska.
Kama tafakari usanidi katika Git? Je, ninakaguaje mabadiliko yaliyofanywa kwenye nguzo?
Jinsi ya kuhakikisha kuzaliana usanidi ukiwashwa tena?
...

Ni wazi kuwa mbinu hii haiendani vizuri na kuhifadhi nambari ya maombi na miundombinu kama nambari (IaC; au hata GitOps (kama chaguo la kisasa zaidi kupata umaarufu katika mfumo wa ikolojia wa Kubernetes). Kwa hivyo, amri hizi katika kubectl hazijaendelezwa zaidi.

Unda, pata, badilisha na ufute shughuli

Pamoja na msingi uumbaji Ni rahisi: tunatuma faili ya maelezo kwa operesheni create API ya kube na rasilimali imeundwa. Uwakilishi wa YAML wa faili ya maelezo inaweza kuhifadhiwa katika Git, na ili kuiunda, tumia amri kubectl create -f manifest.yaml.

С kuondolewa pia ni rahisi: tunabadilisha sawa manifest.yaml kutoka Git hadi timu kubectl delete -f manifest.yaml.

Operesheni replace Inakuruhusu kubadilisha kabisa usanidi wa rasilimali na mpya, bila kuunda tena rasilimali. Hii ina maana kwamba kabla ya kufanya mabadiliko kwa rasilimali, ni jambo la busara kuomba toleo la sasa na uendeshaji get, ibadilishe na usasishe na uendeshaji replaceKube ina apiserver iliyojengwa ndani. kufungia kwa matumaini na ikiwa baada ya upasuaji get kitu kimebadilika, basi operesheni replace haitafanya kazi.

Ili kuhifadhi usanidi katika Git na kusasisha kwa kutumia replace, unahitaji kufanya operesheni get, unganisha usanidi kutoka kwa Git na kile tulichopata, na uendeshe replaceKwa chaguo-msingi, kubectl hukuruhusu tu kutumia amri kubectl replace -f manifest.yamlAmbapo manifest.yaml — faili iliyotayarishwa kikamilifu (kwa upande wetu, imeunganishwa) ambayo inahitaji kusakinishwa. Hii inamaanisha kuwa mtumiaji anahitaji kuunganisha maonyesho, ambayo si kazi ndogo...

Inafaa pia kuzingatia kwamba ingawa manifest.yaml na imehifadhiwa katika Git, hatuwezi kujua mapema kama kitu kinahitaji kuundwa au kusasishwa—hii lazima ifanywe na programu ya mtumiaji.

Jumla: Je, tunaweza kuunda uchapishaji unaoendelea? kwa kutumia tu kuunda, kubadilisha, na kufuta, kuhakikisha kuwa usanidi wa miundombinu umehifadhiwa kwenye Git pamoja na msimbo na CI/CD inayofaa?

Kimsingi, tunaweza ... Kwa hili itakuwa muhimu kutekeleza operesheni ya kuunganisha ilani na aina fulani ya kufunga, ambayo:

huangalia uwepo wa kitu kwenye nguzo,
hufanya uundaji wa awali wa rasilimali,
kuisasisha au kuifuta.

Wakati wa kusasisha, tafadhali kumbuka hilo rasilimali inaweza kuwa iliyopita tangu mwisho get na kushughulikia kiotomatiki kesi ya kufunga kwa matumaini - fanya majaribio ya mara kwa mara kusasisha.

Walakini, kwa nini anzisha tena gurudumu wakati kube-apiserver inatoa njia nyingine ya kusasisha rasilimali: operesheni patch, ambayo humwondolea mtumiaji baadhi ya matatizo yaliyoelezwa?

kiraka

Kwa hivyo, hatimaye tumefikia viraka.

Viraka ndio njia msingi ya kutumia mabadiliko kwa vitu vilivyopo katika Kubernetes. Uendeshaji patch inafanya kazi kwa njia ambayo:

Mtumiaji wa kube-apiserver anahitaji kutuma kiraka katika umbizo la JSON na kubainisha kitu,
na apiserver yenyewe itashughulika na hali ya sasa ya kitu na kuileta kwa fomu inayotakiwa.

Kufunga kwa matumaini hakuhitajiki katika kesi hii. Operesheni hii ni ya kutangaza zaidi kuliko kuchukua nafasi, ingawa inaweza kuonekana kuwa kinyume.

Kwa njia hii:

kwa njia ya upasuaji create tunaunda kitu kulingana na onyesho kutoka kwa Git,
na msaada delete - futa ikiwa kitu hakihitajiki tena,
na msaada patch - tunabadilisha kitu, tukileta kwa fomu iliyoelezwa katika Git.

Hata hivyo, ili kufanya hivyo, unahitaji kuunda kiraka sahihi!

Jinsi Viraka Hufanya kazi katika Helm 2: Njia 2 Huunganishwa

Unaposakinisha toleo la kwanza, Helm hufanya operesheni create kwa rasilimali za chati.

Wakati wa kusasisha toleo la Helm kwa kila nyenzo:

huhesabu kiraka kati ya toleo la rasilimali kutoka kwa chati iliyotangulia na toleo la sasa la chati,
inatumika kiraka hiki.

Tutaita kiraka kama hicho kiraka cha 2-njia-unganisha, kwa sababu ilani mbili zinahusika katika uundaji wake:

udhihirisho wa rasilimali kutoka kwa toleo lililopita,
dhihirisho la rasilimali kutoka kwa rasilimali ya sasa.

Wakati wa kufuta operesheni delete Katika kube, apiserver inaitwa kwa rasilimali ambazo zilitangazwa katika toleo la awali lakini hazijatangazwa katika toleo la sasa.

Mbinu ya kuunganisha kwa njia 2 ina shida: inaongoza kwa kutenganisha hali halisi ya rasilimali kwenye nguzo na faili ya maelezo katika Git.

Kuelezea shida na mfano

Katika Git, chati huhifadhi onyesho ambalo uga image Usambazaji una thamani ubuntu:18.04.
Mtumiaji kupitia kubectl edit ilibadilisha thamani ya uwanja huu kuwa ubuntu:19.04.
Wakati wa kupeleka tena chati ya Helm haitoi kiraka, kwa sababu shamba image katika toleo la awali la toleo na katika chati ya sasa ni sawa.
Baada ya kusambaza upya image bado ubuntu:19.04, ingawa chati inasema ubuntu:18.04.

Tumeacha kulinganishwa na kupoteza utangazaji.

Rasilimali iliyosawazishwa ni nini?

Kwa ujumla kamili Haiwezekani kupata mechi kati ya faili ya maelezo ya rasilimali kwenye nguzo inayoendesha na faili ya maelezo kutoka kwa Git. Hii ni kwa sababu faili ya maelezo halisi inaweza kuwa na maelezo/lebo za huduma, vyombo vya ziada na data nyingine iliyoongezwa na kuondolewa kutoka kwa rasilimali na baadhi ya vidhibiti. Hatuwezi na hatutaki kuhifadhi data hii kwenye Git. Hata hivyo, tunataka sehemu tulizobainisha kwa uwazi katika Git ziwe na thamani zinazofaa wakati wa matumizi.

Inageuka kuwa ya jumla sana sheria ya rasilimali iliyosawazishwa: Wakati wa kusambaza rasilimali, unaweza tu kubadilisha au kufuta sehemu hizo ambazo zimebainishwa wazi katika faili ya maelezo ya Git (au zilibainishwa katika toleo la awali na sasa zimeondolewa).

kiraka cha 3-njia-unganisha

Wazo kuu kiraka cha 3-njia-unganisha: Tengeneza kiraka kati ya toleo la mwisho lililotumika la faili ya maelezo ya Git na toleo lengwa la faili ya maelezo ya Git, kwa kuzingatia toleo la sasa la faili ya maelezo kutoka kwa nguzo inayoendeshwa. Kiraka kinachotokana lazima kizingatie kanuni ya rasilimali iliyosawazishwa:

sehemu mpya zilizoongezwa kwa toleo lengwa zinaongezwa kupitia kiraka;
sehemu zilizopo awali katika toleo la mwisho lililotumika na zile ambazo hazipo katika toleo lengwa zinawekwa upya kwa kutumia kiraka;
Nyuga katika toleo la sasa la kitu ambacho ni tofauti na toleo lengwa la faili ya maelezo zinasasishwa kwa kutumia kiraka.

Hii ndiyo kanuni ambayo patches huzalishwa. kubectl apply:

toleo la mwisho lililotumika la faili ya maelezo limehifadhiwa katika ufafanuzi wa kitu chenyewe,
lengo - limechukuliwa kutoka kwa faili maalum ya YAML,
sasa - kutoka kwa nguzo inayoendesha.

Sasa kwa kuwa tumeangazia nadharia, ni wakati wa kukuambia tulichofanya katika werf.

Inaweka mabadiliko kwenye werf

Hapo awali, werf, kama Helm 2, ilitumia viraka vya kuunganisha kwa njia 2.

Rekebisha kiraka

Ili kuhamia aina mpya ya viraka - 3-way-merge - hatua ya kwanza tuliyochukua ilikuwa kuanzisha kinachojulikana. kutengeneza mabaka.

Wakati wa kupeleka, kiraka cha kawaida cha kuunganisha kwa njia-2 hutumiwa, lakini werf pia hutoa kiraka ambacho kinaweza kusawazisha hali halisi ya rasilimali na kile kilichoandikwa katika Git (kiraka hiki kimeundwa kwa kutumia sheria sawa ya rasilimali iliyosawazishwa iliyoelezewa hapo juu).

Utenganisho ukitokea, mwisho wa utumaji, mtumiaji hupokea ujumbe wa ONYO na ujumbe unaolingana na kiraka ambacho lazima kitumike ili kurejesha rasilimali katika usawazishaji. Kiraka hiki pia kimeandikwa kwa ufafanuzi maalum. werf.io/repair-patchInachukuliwa kuwa mtumiaji anatumia mikono yake mwenyewe itatumia kiraka hiki: werf haitaitumia kwa kanuni.

Kutengeneza viraka ni kipimo cha muda kinachokuruhusu kujaribu mchakato wa kutengeneza viraka kwa njia 3, lakini haitumii viraka hivi kiotomatiki. Hali hii kwa sasa imewezeshwa na chaguo-msingi.

3-njia-unganisha kiraka kwa matoleo mapya pekee

Kuanzia tarehe 1 Desemba 2019, matoleo ya beta na alpha ya werf yataanza kwa msingi Tumia viraka kamili vya kuunganisha kwa njia 3 ili kutumia mabadiliko kwa matoleo mapya ya Helm pekee yaliyotumwa kupitia werf. Matoleo yaliyopo yataendelea kutumia mbinu ya 2-way-merge + kurekebisha kiraka.

Hali hii ya uendeshaji inaweza kuwezeshwa kwa uwazi kwa kuweka WERF_THREE_WAY_MERGE_MODE=onlyNewReleases sasa.

Kumbuka: kipengele kilionekana katika werf juu ya matoleo kadhaa: katika kituo cha alfa ikawa tayari na toleo v1.0.5-alpha.19, na katika kituo cha beta - na v1.0.4-beta.20.

Njia-3-unganishi kiraka kwa matoleo yote

Kuanzia tarehe 15 Desemba 2019, matoleo ya beta na alpha ya werf yatatumia viraka vya kuunganisha kwa njia 3 kwa chaguomsingi ili kutekeleza mabadiliko kwa matoleo yote.

Hali hii ya uendeshaji inaweza kuwezeshwa kwa uwazi kwa kuweka WERF_THREE_WAY_MERGE_MODE=enabled sasa.

Jinsi ya kushughulikia rasilimali otomatiki?

Kuna aina mbili za kupima otomatiki katika Kubernetes: HPA (mlalo) na VPA (wima).

Mlalo huchagua moja kwa moja idadi ya nakala, wakati moja ya wima huchagua idadi ya rasilimali. Idadi ya nakala na mahitaji ya rasilimali imebainishwa kwenye faili ya maelezo ya rasilimali (ona spec.replicas au spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory и wengine).

Tatizo: Ikiwa mtumiaji atasanidi nyenzo katika chati ili ibainishe thamani mahususi za rasilimali au nakala, na viboreshaji kiotomatiki vimewashwa kwa nyenzo hii, basi kwa kila uwekaji, werf itaweka upya thamani hizi kwa kile kilichoandikwa kwenye faili ya maelezo ya chati.

Kuna masuluhisho mawili ya tatizo hili. Njia bora ya kuanza ni kuepuka kubainisha kwa uwazi thamani za kuongeza kiotomatiki kwenye faili ya maelezo ya chati. Ikiwa chaguo hili halifai kwa sababu fulani (kwa mfano, kwa sababu ni rahisi kubainisha vikomo vya awali vya rasilimali na idadi ya nakala kwenye chati), werf inatoa maelezo yafuatayo:

werf.io/set-replicas-only-on-creation=true
werf.io/set-resources-only-on-creation=true

Kwa kidokezo hiki, werf haitaweka upya thamani zinazolingana kwenye kila utumaji, lakini itaziweka tu wakati rasilimali imeundwa hapo awali.

Kwa maelezo zaidi, angalia hati za mradi. HPA и VPA.

Zima matumizi ya kiraka cha njia-3

Mtumiaji kwa sasa anaweza kulemaza matumizi ya viraka vipya kwenye werf kwa kutumia kitofauti cha mazingira. WERF_THREE_WAY_MERGE_MODE=disabledHata hivyo, kuanzia Marufuku haya hayatatumika tena kuanzia tarehe 1 Machi 2020. na itawezekana kutumia viraka vya kuunganisha njia 3 pekee.

Kupitishwa kwa rasilimali katika werf

Kujua mbinu ya kuunganisha kwa njia-3 ya kutumia mabadiliko kulituruhusu kutekeleza kipengele mara moja kama vile upitishaji wa nyenzo zilizopo za nguzo katika toleo la Helm.

Helm 2 ina tatizo: huwezi kuongeza nyenzo kwenye faili ya maelezo ya chati ambayo tayari ipo kwenye kundi bila kuunda tena rasilimali hiyo kutoka mwanzo (tazama hapa chini). #6031, #3275) Tumefundisha werf kukubali nyenzo zilizopo kwenye toleo. Ili kufanya hivyo, unahitaji kusakinisha kidokezo kwenye toleo la sasa la rasilimali kutoka kwa nguzo inayoendesha (kwa mfano, kutumia kubectl edit):

"werf.io/allow-adoption-by-release": RELEASE_NAME

Sasa rasilimali inahitaji kuelezewa kwenye chati, na wakati mwingine werf ikitumia toleo lenye jina linalolingana, rasilimali iliyopo itakubaliwa katika toleo hilo na kubaki chini ya usimamizi wake. Zaidi ya hayo, wakati wa mchakato wa kukubali rasilimali katika toleo, werf itabadilisha hali ya sasa ya rasilimali kutoka kwa nguzo inayoendeshwa hadi hali iliyofafanuliwa kwenye chati, kwa kutumia viraka sawa vya njia-3 na sheria ya rasilimali iliyosawazishwa.

Kumbuka: kuweka WERF_THREE_WAY_MERGE_MODE haiathiri kupitishwa kwa rasilimali - katika kesi ya kupitishwa, kiraka cha kuunganisha kwa njia 3 hutumiwa kila wakati.

Maelezo yapo nyaraka.

Hitimisho na mipango ya baadaye

Natumai nakala hii imeweka wazi zaidi viraka vya kuunganisha kwa njia 3 ni kwa nini vilichaguliwa. Kutoka kwa mtazamo wa vitendo kwa mradi wa werf, utekelezaji wao unaashiria hatua nyingine kuelekea kuboresha uwekaji kama Helm. Masuala ya ulandanishi wa usanidi ambayo yalizuka mara kwa mara na Helm 2 sasa yanaweza kusahaulika. Wakati huo huo, kipengele kipya, muhimu kimeongezwa: kupitisha rasilimali za Kubernetes tayari zilizotumwa kwenye toleo la Helm.

Bado kuna baadhi ya masuala na changamoto za uwekaji kama vile Helm, kama vile matumizi ya violezo vya Go, na tutaendelea kuzishughulikia.

Taarifa juu ya mbinu za kusasisha rasilimali na kupitishwa pia zinaweza kupatikana katika ukurasa huu wa nyaraka.

Helm 3

Inastahili kutajwa maalum iliyotolewa Siku nyingine tu, toleo jipya kuu la Helm-v3-lilitolewa, ambalo pia hutumia viraka vya kuunganisha njia-3 na kuondoa Tiller. Toleo jipya la Helm linahitaji uhamiaji usakinishaji uliopo ili kuzibadilisha hadi umbizo jipya la hifadhi ya toleo.

Werf, kwa upande wake, sasa ameondoa matumizi ya Tiller, akabadilisha hadi 3-way-merge na kuongeza. mengi zaidi, huku ikisalia sambamba na usakinishaji uliopo wa Helm 2 (hakuna hati za uhamiaji zinazohitajika). Kwa hivyo, hadi werf ibadilike kwa Helm 3, watumiaji wa werf hawatapoteza faida muhimu za Helm 3 juu ya Helm 2 (werf pia ina faida hizi).

Hata hivyo, ubadilishaji wa werf hadi Helm 3 codebase hauwezi kuepukika na utafanyika hivi karibuni. Hii inaweza kuwa werf 1.1 au werf 1.2 (kwa sasa, toleo kuu la werf ni 1.0; kwa habari zaidi juu ya toleo la werf, ona hapa) Wakati huu, Helm 3 itakuwa na wakati wa utulivu.