Kile sisi (na sio sisi tu) tumekuwa tukingojea kwa muda mrefu kilifanyika: , shirika letu la Open Source kwa ajili ya kuunda programu na kuziwasilisha kwa Kubernetes, sasa inasaidia kutumia mabadiliko kwa kutumia viraka vya kuunganisha kwa njia 3! Kwa kuongeza hii, inawezekana kupitisha rasilimali zilizopo za K8s katika matoleo ya Helm bila kujenga upya rasilimali hizi.
Ikiwa ni fupi sana, basi 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 viraka gani hasa vya njia-3, watu walikuja na mbinu gani ya kuzizalisha, na kwa nini ni muhimu katika michakato ya CI/CD na miundombinu inayotegemea Kubernetes? Na baada ya hayo, hebu tuone 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 zilizoelezewa katika YAML inajidhihirisha katika Kubernetes.
Ili kufanya kazi na rasilimali, Kubernetes API inatoa shughuli za msingi zifuatazo: kuunda, kiraka, kubadilisha na kufuta. Inafikiriwa kuwa kwa msaada wao ni muhimu kuunda usambazaji rahisi wa rasilimali kwa nguzo. Vipi?
kubectl amri za lazima
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 rununaweza 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 vigumu automatiska.
- Kama tafakari usanidi katika Git? Jinsi ya kukagua mabadiliko yanayotokea kwenye nguzo?
- Jinsi ya kutoa kuzaliana usanidi ukiwashwa tena?
- ...
Ni wazi kuwa mbinu hii haiendani vyema na uhifadhi wa programu na miundombinu kama nambari (IaC; au hata kama chaguo la kisasa zaidi, kupata umaarufu katika mfumo wa ikolojia wa Kubernetes). Kwa hivyo, amri hizi hazikupokea maendeleo zaidi katika kubectl.
Unda, pata, badilisha na ufute shughuli
Pamoja na msingi uumbaji ni rahisi: tuma faili ya maelezo kwa operesheni create kube api na rasilimali imeundwa. Uwakilishi wa YAML wa faili ya maelezo unaweza kuhifadhiwa katika Git na kuundwa kwa kutumia amri kubectl create -f manifest.yaml.
Π‘ kuondolewa pia rahisi: mbadala sawa manifest.yaml kutoka Git hadi timu kubectl delete -f manifest.yaml.
Operesheni replace hukuruhusu kubadilisha kabisa usanidi wa rasilimali na mpya, bila kuunda tena rasilimali. Hii ina maana kwamba kabla ya kufanya mabadiliko kwa rasilimali, ni busara kuuliza toleo la sasa na uendeshaji get, ibadilishe na usasishe na uendeshaji replace. kube apiserver imejengwa ndani na, ikiwa ni 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 tulichopokea, na utekeleze replace. Kwa chaguo-msingi, kubectl hukuruhusu tu kutumia amri kubectl replace -f manifest.yamlAmbapo manifest.yaml β faili ya maelezo ambayo tayari imetayarishwa kikamilifu (kwa upande wetu, imeunganishwa) ambayo inahitaji kusakinishwa. Inabadilika kuwa mtumiaji anahitaji kutekeleza ujumuishaji wa maonyesho, na hii sio jambo dogo ...
Inafaa pia kuzingatia kwamba ingawa manifest.yaml na imehifadhiwa katika Git, hatuwezi kujua mapema ikiwa ni muhimu kuunda kitu au kusasisha - hii lazima ifanywe na programu ya mtumiaji.
Jumla: 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 utahitaji kutekeleza operesheni ya kuunganisha ilani na aina fulani ya kufunga kwamba:
- huangalia uwepo wa kitu kwenye nguzo,
- hufanya uundaji wa rasilimali za awali,
- kuisasisha au kuifuta.
Wakati wa kusasisha, tafadhali kumbuka kuwa rasilimali inaweza kuwa iliyopita tangu mwisho get na kushughulikia kiotomatiki kesi ya kufunga kwa matumaini - fanya majaribio ya kusasisha mara kwa mara.
Walakini, kwa nini anzisha tena gurudumu wakati kube-apiserver inatoa njia nyingine ya kusasisha rasilimali: operesheni patch, ambayo hupunguza mtumiaji wa baadhi ya matatizo yaliyoelezwa?
kiraka
Sasa tunafika kwenye patches.
Viraka ndio njia msingi ya kutumia mabadiliko kwa vitu vilivyopo katika Kubernetes. Operesheni patch inafanya kazi kama hii:
- mtumiaji wa kube-apiserver anahitaji kutuma kiraka katika fomu ya 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 mwanzoni inaweza kuonekana kuwa kinyume.
Kwa njia hii:
- kwa kutumia operesheni
createtunaunda kitu kulingana na dhihirisho kutoka kwa Git, - na msaada
delete- futa ikiwa kitu haihitajiki tena, - na msaada
patch- tunabadilisha kitu, tukileta kwa fomu iliyoelezwa katika Git.
Hata hivyo, kwa kufanya hivyo, unahitaji kuunda kiraka sahihi!
Jinsi viraka hufanya kazi katika Helm 2: 2-way-merge
Unaposakinisha toleo la kwanza, Helm hufanya operesheni create kwa rasilimali za chati.
Wakati wa kusasisha toleo la Helm kwa kila nyenzo:
- inazingatia kiraka kati ya toleo la rasilimali kutoka kwa chati iliyotangulia na toleo la sasa la chati,
- inatumika kiraka hiki.
Tutaita kiraka hiki kiraka cha kuunganisha kwa njia 2, kwa sababu manifesto 2 zinahusika katika uundaji wake:
- udhihirisho wa rasilimali kutoka toleo lililopita,
- dhihirisho la rasilimali kutoka kwa rasilimali ya sasa.
Wakati wa kuondoa operesheni delete katika kube apiserver inaitwa kwa rasilimali ambazo zilitangazwa katika toleo la awali, lakini hazijatangazwa katika toleo la sasa.
Njia 2 ya kuunganisha kiraka ina shida: inaongoza kwa nje ya usawazishaji na hali halisi ya rasilimali kwenye nguzo na faili ya maelezo katika Git.
Mchoro wa shida na mfano
- Katika Git, chati huhifadhi faili ya maelezo ambayo uwanja huo
imageMambo ya kupelekaubuntu:18.04. - Mtumiaji kupitia
kubectl editilibadilisha thamani ya uwanja huu kuwaubuntu:19.04. - Wakati wa kupeleka tena chati ya Helm haitoi kiraka, kwa sababu shamba
imagekatika toleo la awali la toleo na katika chati ya sasa ni sawa. - Baada ya kupelekwa tena
imagebadoubuntu:19.04, ingawa chati inasemaubuntu:18.04.
Tulipata kutosawazisha na kupoteza utangazaji.
Rasilimali iliyosawazishwa ni nini?
Kwa ujumla ΠΏΠΎΠ»Π½ΠΎΠ΅ Haiwezekani kupata ulinganifu kati ya faili ya maelezo ya rasilimali katika nguzo inayoendesha na faili ya maelezo kutoka kwa Git. Kwa sababu katika faili ya maelezo halisi kunaweza kuwa na maelezo/lebo za huduma, kontena za ziada na data nyingine ambayo huongezwa na kuondolewa kutoka kwa rasilimali kwa nguvu na baadhi ya vidhibiti. Hatuwezi na hatutaki kuweka data hii kwenye Git. Hata hivyo, tunataka sehemu ambazo tulibainisha kwa uwazi kwenye Git zichukue thamani zinazofaa baada ya kuchapishwa.
Inageuka hivyo kwa ujumla sheria ya rasilimali iliyosawazishwa: wakati wa kusambaza rasilimali, unaweza kubadilisha au kufuta sehemu zile tu ambazo zimebainishwa wazi katika faili ya maelezo kutoka Git (au zilibainishwa katika toleo la awali na sasa zimefutwa).
kiraka cha kuunganisha kwa njia 3
Wazo kuu : tunatoa kiraka kati ya toleo la mwisho lililotumika la faili ya maelezo kutoka Git na toleo lengwa la faili ya maelezo kutoka Git, kwa kuzingatia toleo la sasa la faili ya maelezo kutoka kwa nguzo inayoendesha. Kiraka kinachotokana lazima kizingatie kanuni ya rasilimali iliyosawazishwa:
- mashamba mapya yaliyoongezwa kwenye toleo lengwa huongezwa kwa kutumia kiraka;
- sehemu zilizopo awali katika toleo la mwisho lililotumika na ambazo hazipo katika toleo lengwa zinawekwa upya kwa kutumia kiraka;
- sehemu katika toleo la sasa la kitu ambacho ni tofauti na toleo lengwa la faili ya maelezo zinasasishwa kwa kutumia kiraka.
Ni kwa kanuni hii kwamba inazalisha patches kubectl apply:
- toleo la mwisho lililotumika la faili ya maelezo limehifadhiwa katika ufafanuzi wa kitu chenyewe,
- lengo - limechukuliwa kutoka kwa faili maalum ya YAML,
- ya sasa ni kutoka kwa nguzo inayoendesha.
Sasa kwa kuwa tumepanga nadharia, ni wakati wa kukuambia kile tulichofanya kwenye werf.
Inaweka mabadiliko kwenye werf
Hapo awali, werf, kama Helm 2, ilitumia viraka vya kuunganisha kwa njia 2.
Rekebisha kiraka
Ili kubadili aina mpya ya viraka - 3-njia-unganisha - hatua ya kwanza tulianzisha 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 kama hicho huundwa kwa kutumia sheria sawa ya rasilimali iliyosawazishwa iliyoelezewa hapo juu) .
Iwapo utenganishaji utatokea, mwisho wa utumaji mtumiaji hupokea ONYO na ujumbe unaolingana na kiraka ambacho lazima kitumike ili kuleta rasilimali kwenye fomu iliyosawazishwa. Kiraka hiki pia kinarekodiwa katika ufafanuzi maalum werf.io/repair-patch. Inachukuliwa kuwa mikono ya mtumiaji mwenyewe itatumia kiraka hiki: werf haitaitumia hata kidogo.
Kuzalisha viraka vya urekebishaji ni kipimo cha muda ambacho hukuruhusu kujaribu uundaji wa viraka kulingana na kanuni ya kuunganisha njia-3, lakini usitumie viraka hivi kiotomatiki. Kwa sasa, hali hii ya uendeshaji imewezeshwa na chaguo-msingi.
3-njia-unganisha kiraka kwa matoleo mapya pekee
Kuanzia tarehe 1 Desemba 2019, matoleo ya beta na alpha ya werf yanaanza kwa msingi tumia viraka kamili vya njia-3 ili kutumia mabadiliko kwa matoleo mapya ya Helm yanayotolewa kupitia werf. Matoleo yaliyopo yataendelea kutumia mbinu ya 2-way-merge + kurekebisha viraka.
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 , na katika kituo cha beta - na .
Njia-3-unganishi kiraka kwa matoleo yote
Kuanzia tarehe 15 Desemba 2019, matoleo ya beta na alpha ya werf yataanza kutumia viraka kamili vya njia-3 kwa chaguo-msingi ili kutekeleza mabadiliko kwenye matoleo yote.
Hali hii ya uendeshaji inaweza kuwezeshwa kwa uwazi kwa kuweka WERF_THREE_WAY_MERGE_MODE=enabled sasa.
Nini cha kufanya na kuongeza rasilimali kiotomatiki?
Kuna aina 2 za kupima kiotomatiki katika Kubernetes: HPA (mlalo) na VPA (wima).
Mlalo huchagua moja kwa moja idadi ya nakala, wima - idadi ya rasilimali. Idadi ya nakala na mahitaji ya rasilimali imebainishwa katika faili ya maelezo ya rasilimali (angalia Rasilimali Wazi). spec.replicas au spec.containers[].resources.limits.cpu, spec.containers[].resources.limits.memory ΠΈ ).
Tatizo: ikiwa mtumiaji atasanidi rasilimali katika chati ili ibainishe thamani fulani za rasilimali au nakala na vidhibiti otomatiki vimewezeshwa kwa rasilimali hii, basi kwa kila uwekaji werf itaweka upya thamani hizi kwa kile kilichoandikwa kwenye faili ya maelezo ya chati. .
Kuna masuluhisho mawili ya tatizo. Kuanza, ni vyema kuepuka kubainisha kwa uwazi thamani zilizowekwa kiotomatiki katika faili ya maelezo ya chati. Ikiwa chaguo hili halifai kwa sababu fulani (kwa mfano, kwa sababu ni rahisi kuweka mipaka ya awali ya rasilimali na idadi ya nakala kwenye chati), basi werf inatoa maelezo yafuatayo:
-
werf.io/set-replicas-only-on-creation=true -
werf.io/set-resources-only-on-creation=true
Ikiwa kidokezo kama hicho kipo, werf haitaweka upya thamani zinazolingana kwenye kila uwekaji, lakini itaziweka tu wakati rasilimali imeundwa hapo awali.
Kwa maelezo zaidi, angalia hati za mradi za ΠΈ .
Kataza matumizi ya kiraka cha kuunganisha njia-3
Mtumiaji kwa sasa anaweza kupiga marufuku matumizi ya viraka vipya kwenye werf kwa kutumia kigezo cha mazingira WERF_THREE_WAY_MERGE_MODE=disabled. Hata hivyo, kuanzia Kuanzia Machi 1, 2020, marufuku haya hayatatumika tena. na itawezekana kutumia viraka vya kuunganisha kwa njia 3 pekee.
Kupitishwa kwa rasilimali katika werf
Kujua mbinu ya kutumia mabadiliko na viraka vya kuunganisha kwa njia-3 kulituruhusu kutekeleza mara moja kipengele kama vile kupitisha rasilimali zilizopo kwenye nguzo kwenye toleo la Helm.
Helm 2 ina shida: huwezi kuongeza rasilimali kwenye maonyesho ya chati ambayo tayari yapo kwenye nguzo bila kuunda tena rasilimali hii kutoka mwanzo (ona. , ) Tulifundisha werf kukubali rasilimali zilizopo ili kutolewa. 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_NAMESasa rasilimali inahitaji kuelezewa kwenye chati na wakati mwingine werf ikitumia toleo lenye jina linalofaa, rasilimali iliyopo itakubaliwa katika toleo hili na kubaki chini ya udhibiti wake. Zaidi ya hayo, katika mchakato wa kukubali rasilimali kwa ajili ya kutolewa, werf italeta hali ya sasa ya rasilimali kutoka kwa nguzo inayoendesha hadi hali iliyoelezwa kwenye chati, kwa kutumia viraka sawa vya njia 3 na kanuni 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 - ndani .
Hitimisho na mipango ya baadaye
Natumai kuwa baada ya nakala hii imekuwa wazi zaidi ni viraka gani vya kuunganisha kwa njia 3 na kwa nini walikuja kwao. Kwa mtazamo wa vitendo wa maendeleo ya mradi wa werf, utekelezaji wao ulikuwa hatua nyingine kuelekea kuboresha uwekaji kama Helm. Sasa unaweza kusahau kuhusu matatizo na maingiliano ya usanidi, ambayo mara nyingi yalitokea wakati wa kutumia Helm 2. Wakati huo huo, kipengele kipya muhimu cha kupitisha rasilimali za Kubernetes zilizopakuliwa tayari ziliongezwa kwenye kutolewa kwa Helm.
Bado kuna baadhi ya masuala na changamoto za matumizi kama vile Helm, kama vile matumizi ya violezo vya Go, ambazo tutaendelea kushughulikia.
Taarifa kuhusu mbinu za kusasisha rasilimali na kupitishwa pia zinaweza kupatikana katika .
Helm 3
Inastahili kuzingatiwa maalum siku nyingine tu toleo jipya kuu la Helm - v3 - ambalo pia hutumia viraka vya kuunganisha njia-3 na kuondoa Tiller. Toleo jipya la Helm linahitaji usakinishaji uliopo ili kuzibadilisha kuwa muundo mpya wa hifadhi ya toleo.
Werf, kwa upande wake, kwa sasa ameachana na matumizi ya Tiller, akabadilisha hadi 3-way-merge na kuongezwa. , huku ikisalia sambamba na usakinishaji uliopo wa Helm 2 (hakuna hati za uhamiaji zinazohitaji kutekelezwa). Kwa hivyo, hadi swichi za werf hadi Helm 3, watumiaji wa werf hawapotezi faida kuu za Helm 3 juu ya Helm 2 (werf pia inayo).
Hata hivyo, ubadilishaji wa werf hadi Helm 3 codebase hauwezi kuepukika na utafanyika hivi karibuni. Labda hii itakuwa werf 1.1 au werf 1.2 (kwa sasa, toleo kuu la werf ni 1.0; kwa habari zaidi kuhusu kifaa cha toleo la werf, ona ) Wakati huu, Helm 3 itakuwa na wakati wa utulivu.
PS
Soma pia kwenye blogi yetu:
- Msururu wa maelezo kuhusu uvumbuzi katika werf:
- Β«";
- Β«";
- Β«'.
- Β«";
- Β«";
- Β«'.
Chanzo: mapenzi.com