Helm սարքը և դրա ենթահիմնադրությունները

Typhon բեռափոխադրող կոնցեպցիա, Anton Swanepoel

Ես ինձ վերանվանում եմ Դմիտրի Սուգրոբով, ես ծրագրավորող եմ «Լերուա Մեռլեն»-ում: Այս հոդվածում կներկայացնեմ, թե ինչու է անհրաժեշտ Helm-ը, ինչպես է այն հեշտացնում Kubernetes-ի հետ աշխատելը, ինչ փոփոխություններ են եղել երրորդ տարբերակում և ինչպես նրա միջոցով թարմացնել հավելվածները արտադրությունում առանց դադարների:

Այս փաստաթուղթը ներառում է հիմնական نقاطները խոսնակի ելույթի հիման վրա @Kubernetes Conference by Mail.ru Cloud Solutions — եթե չեք ցանկանում կարդալ, դիտեք տեսանյութը:

Ինչու ենք մենք օգտագործում Kubernetes արտադրությունում

«Լերուա Մեռլեն» — DIY-մանրածախ առևտրի շուկայում ղեկավար է Ռուսաստանում և Եվրոպայում: Մեր ընկերությունում ավելի քան հարյուր ծրագրավորող կա, 33,000 ներքին աշխատակից և բազմաթիվ մարդիկ, որոնք այցելում են հիպերմարկետները և կայքը: Ընկերության բոլոր նրանց ուրախացնելու համար մենք որոշեցինք հետևել արդյունաբերության ստանդարտների: Նոր հավելվածներ մշակելու համար օգտագործելով միկրոսերվիսային ճարտարապետություն, միջավայրերը մեկուսացնելու և պատշաճ մատակարարում ապահովելու համար օգտագործելով կոնտեյներներ, իսկ կազմակերպման համար օգտագործելով Kubernetes: Օգտագործողների համար կազմակերպիչների գինը արագորեն նվազում է, շուկայում ավելանում են տեխնոլոգիան掌握ող ինժենере, լինում են մատակարարներ, որոնք առաջարկում են Kubernetes որպես ծառայություն:

Բոլո՞րն այն, ինչ անում է Kubernetes-ը, իհարկե, կարելի է իրականացնել այլ եղանակներով, օրինակ, ինչ-որ Ջենկինս-ի միջոցով և docker-compose-ի կիրառմամբ, բայց ինչու լարում կյանքը, եթե կա պատրաստի և վստահելի լուծում: Ուստի մենք անցանք Kubernetes-ի և արդեն մեկ տարի օգտագործում ենք այն արտադրությունում: Այժմ մենք ունենք քսան չորս Kubernetes կլաստեր, ամենահինը մեկ տարուց ավել է, այնտեղ ավելի քան երկու հարյո՛ւ պոդ է:

Կուրբեցման մեծ քանակի YAML-ֆայլերի աշխատելիս

Մի միկրոսերվիս սկսելիս Kubernetes-ում պետք է ստեղծենք անպայման հինգ YAML-ֆայլ: Deployment, Service, Ingress, ConfigMap, Secrets — և դրանք կուղարկենք կլաստեր: Գագաթային սոցիալականի համար գրանցենք նույն մանկածրագրի ասումները, արդեն երրորդը — ևս մեկը, և այլն: Յուրաքանչյուր փաստաթուղթ բազմապատկվում է միջավայրերի քանակով, ու այժմ ստանում ենք հարյուրավոր ֆայլեր, և սա դեռ չի հաշվում դինամիկ միջավայրերը:

Adam Reese, Helm-ի հիմնական պահպանողը, մտցրեց «Kubernetes-ում զարգացման շրջանը», որը выглядит так:

1. Copy YAML — ստանալ YAML-ֆայլը:
2. Paste YAML — տեղադրել այն:
3. Fix Indents — ուղղել ներվի հեռացող փոխանցումները:
4. Repeat — կրկնել նորից:

Այս տարբերակը աշխատանքային է, բայց պետք է շատ անգամներ կրկնել YAML-ֆայլերը: Այս շրջանը փոխելու համար, և սարքեցին Helm-ը:

Ինչ է Helm-ը

Առաջին հերթին, Helm-ը — փաթեթների կառավարիչ, որն օգնում է գտնել և տեղադրել անհրաժեշտ ծրագրեր: Օրինակ, MongoDB-ի տեղադրման համար անհրաժեշտ չէ այցելել պաշտոնական կայքը և ներբեռնել բինարներ, բավական է կատարել հրահանգը helm install stable/mongodb.

Երկրորդ, Helm-ը — մանկացավագործող, օգնում է պարամետրիզացնել ֆայլերը: Վերադառնանք Kubernetes-ի YAML-ֆայլերի իրավիճակին: Երեք անգամ ավելի հեշտ է գրել նույն YAML ֆայլը, ավելացնել որոշ placeholder-ներ, որոնց Helm-ն կտեղադրի արժեքները: Դա նշանակում է, որ մեծ YAML ֆայլերի փոխարեն կլինի թեմպլեյտների հավաքածու, որոնց մեջ անհրաժեշտ պահին կտեղադրվեն անհրաժեշտ արժեքները:

Երրորդ՝ Helm — ներդրումների վարպետ. Նրա օգնությամբ կարելի է տեղադրում, վերադարձնել ու թարմացնել հավելվածները: Դե, եկեք հասկանանք՝ ինչպես դա անել:

Ինչպես օգտագործել Helm-ը սեփական հավելվածների տեղադրման համար

Եկեք տեղադրենք Helm հաճախորդը մեր համակարգչին՝ հետևելով պաշտոնական հ οδηγίες. Հետո ստեղծենք YAML ֆայլերի հավաքածու: Կոնկրետ արժեքներ նշել փոխարեն թողնենք placeholder-ներ, որոնք ապագայում Helm-ը կլրացնի տեղեկատվությամբ: Դրա նման ֆայլերի հավաքածուն կոչվում է Helm չարտ: Պետք է կարողանալ այն ուղարկել Helm հրամանական հաճախորդի երեք եղանակով՝

• նշելով թեմպլեյտների ֆոլդերը;
• փաթեթավորելով .tar արխիվում և նշելով այն;
• տեղադրելով template-ը հեռավոր ռեպոզիտորիայում և ավելացնելով այն ռեպոզիտորիայի հղումը Helm հաճախորդում:

Այսպիսով, անհրաժեշտ է նաև արժեքների ֆայլ՝ values.yaml: Տվյալները այնտեղից կավելացվեն թեմպլեն: Ստեղծենք նաև դա:

Helm-ի երկրորդ տարբերակում կա ավելորդ սերվերային ծրագիր՝ Tiller: Այն կախված է Kubernetes-ի արտաքին կողմում ու սպասում է Helm հաճախորդի հարցումներ, եւ երբ պահանջվում է՝ տեղադրում է անհրաժեշտ արժեքները թեմպլում և ուղարկում Kubernetes-ին:

Helm 3-ը ավելի պարզ է. փոխարենը սերվերի կողմում թեմպլենների մշակման, տեղեկատվությունը այժմ ամբողջությամբ մշակվում է Helm հաճախորդի կողմից և ուղարկվում անմիջապես Kubernetes API-ին: Սա հեշտացնում է կլաստերի անվտանգությունը և պարզեցնում տեղադրումը:

Ինչպես ամեն ինչ աշխատում է

Մենք ակտիվացնում ենք հրամանը helm install. Ցուցադրում ենք հավելվածի թողարկման անունը, տալիս ենք ճանապարհը մինչև values.yaml: Ի վերջո նշում ենք այն ռեպոզիտորիան, որտեղ գտնվում է չարտը և չարտի անվանումը: Օրինակ այս դեպքում «lmru» և «bestchart» համապատասխանաբար:

helm install --name bestapp --values values.yaml lmru/bestchart

Հրամանի կատարումը հնարավոր է միայն մեկ անգամ, կրկնակի կատարելու դեպքում պետք է օգտագործել install upgrade . Որպես ուղղակիություն, երկու հրաման փոխարեն կարելի է կատարել հրամանըմի հավելյալ բանով . Որպես ուղղակիություն, երկու հրաման փոխարեն կարելի է կատարել հրամանը --install . Առաջին կատարումն, Helm-ն կուղարկի հրամանը թողարկման տեղադրման համար, իսկ հետագայում այն կթարմացնի:helm upgrade --install bestapp --values values.yaml lmru/bestchart

Դեպքերս նոր տարբերակների տեղադրման համար Helm-ի հետ

Այս պատմության այս պահին ես խաղում եմ «Ով ուզում է դառնալ միլիոնատեր» խաղում, և մենք փորձում ենք հասկանալ, թե ինչպես ստիպել Helm-ին թարմացնել հավելվածի տարբերակը:

Դիտել վիդեո Смотреть видео.

Երբ ես ուսումնասիրում էի Helm-ը, ինձ զարմացրեց տարօրինակ վարքը, երբ փորձում էի թարմացնել գործարկված հավելվածների տարբերակները: Հավելվածի կոդը թարմացվեց, docker registry-ում նոր կերպար载նելը էի, դրանով հանդերձ, ես ուղարկել էի տեղակայման հրամանը - և ոչինչ տեղի չունեցավ: Ահա մեկ քանի ոչ այնքան հաջողված մեթոդներ հավելվածների թարմացման համար: Յուրաքանչյուրը մանրամասն ուսումնասիրելով, սկսում ես հասկանալ գործիքի ներքին կառուցվածքը և նման անսպասելի վարքի պատճառները.

Մեթոդ 1. Այնինչ, չփոխել տեղեկությունները վերջին մեկնարկից հետո

Ինչպես ասվում է մասնագիտական կայք Helm-ի վրա, «Kubernetes շերտերը կարող են լինել մեծ և բարդ, այդ պատճառով Helm-ը փորձում է այնքան փոքր դիպուկ մտնել»: Այսպիսով, եթե թարմացնի latest տարբերակի կերպարը docker registry-ում և կատարի հրամանը helm upgrade, ապա ոչինչ չի տեղի ունենա: Helm-ը կմտածի, թե ոչինչ չի փոխվել և Kubernetes-ին տեղադրելու հրաման չի ուղարկվելու:

Կայքում և հետագայում latest պիտակը ցուցադրվում է բացառապես օրինակ համար: Երբ նշվում է այս պիտակը, Kubernetes-ը ամեն անգամ կկալարակի կերպարը docker registry-ից, անկախ imagePullPolicy պարամետրի վիճակից: Latest-ի օգտագործումը արտադրությունում ցանկալի չէ և կարող է առաջացնել կողմային էֆեկտներ:

Մեթոդ 2. Թարմացնել LABEL-ը կերպարում

Ինչպես վերոնշյալ հոդվածում ասված է, «Helm-ը կթարմացնի հավելվածը միայն այն դեպքում, եթե այն փոխվել է վերջին թողարկումից հետո»: Այս դեպքում անհարկի երևակայություն կթողնի LABEL պիտակները թարմացնել հենց docker կերպարում: Սակայն Helm-ը չի նայում հավելվածների կերպարներին և չունի որևէ տեղեկություն դրանց մասին: Ուստի՝ LABEL-ների թարմացման ժամանակ Helm-ը նույնիսկ չի իմանա դրանց մասին, և Kubernetes-ին հավելվածի թարմացման հրամանը չի փոխանցվի: փաստաթղթավորումըՄեթոդ 3. Օգտագործել բանալին

--force Եկեք նայենք ձեռնարկներին և գտնում ենք անհրաժեշտ բանալին: Ամենագլխավոր իմաստով բանալին ամենաանհարմար է: Այնուամենայնիվ, խոսակցային անվանմամբ, վարքը տարբեր է սպասվողից: Force-ով թարմացրած հավելվածը իրականում նախատեսված է FAILED վիճակում գտնվող թողարկման վերականգնման համար: Եթե չի օգտագործվի այդ բանալին, ապա sequential հրամաններն առաջին կարգով պետք է կատարել՝

helm delete && helm install --replace Եկեք նայենք ձեռնարկներին և գտնում ենք անհրաժեշտ բանալին: Ամենագլխավոր իմաստով բանալին ամենաանհարմար է: Այնուամենայնիվ, խոսակցային անվանմամբ, վարքը տարբեր է սպասվողից: Force-ով թարմացրած հավելվածը իրականում նախատեսված է FAILED վիճակում գտնվող թողարկման վերականգնման համար: Եթե չի օգտագործվի այդ բանալին, ապա sequential հրամաններն առաջին կարգով պետք է կատարել՝. Այս տեղը առաջարկվում է օգտագործել բանալին , որը ավտոմատացնում է այդ հրամանների հաջորդական կատարումը: Վճռական տեղեկանք այս մասինբուրեղ-առավելություն Եկեք նայենք ձեռնարկներին և գտնում ենք անհրաժեշտ բանալին: Ամենագլխավոր իմաստով բանալին ամենաանհարմար է: Այնուամենայնիվ, խոսակցային անվանմամբ, վարքը տարբեր է սպասվողից: Force-ով թարմացրած հավելվածը իրականում նախատեսված է FAILED վիճակում գտնվող թողարկման վերականգնման համար: Եթե չի օգտագործվի այդ բանալին, ապա sequential հրամաններն առաջին կարգով պետք է կատարել՝. Քանի որ Helm-ին ասել, որ իրականում թարմացնի հավելվածի տարբերակը, այդ բանալին, ցավոք, չի հարմարեցվի: Մեթոդ 4. Անձնապես փոխել labels-ը Kubernetes-ումՆրանց ուղղակի թարմացումը կլաստերում վնասակար գաղափար է: Այս գործողությունը կհանգեցնի տեղեկությունների անհամապատասխանության աշխատող հավելվածի միջև և այն, ինչ սկզբում արտփողվեց տեղակայմանը: Helm-ի վարքը տեղակայման ժամանակ այդ դեպքում տարբեր է իր տարբերությունից. Helm 2-ը ոչինչ չի անի, իսկ Helm 3-ը տեղադրելու է նոր տարբերակը հավելվածի: Ինչպես հասկանալ պատճառը, պետք է հասկանալ, թե ինչպես է աշխատում Helm-ը.

Ինչպես աշխատում է Helm-ը

Обновление label напрямую в кластере с помощью команды kubectl edit — плохая идея. Это действие приведёт к неконсистентности информации между работающим приложением и тем, что изначально отправилось на деплой. Поведение Helm при деплое в этом случае отличается от его версии: Helm 2 ничего делать не будет, а Helm 3 задеплоит новую версию приложения. Для понимания причины нужно понять, как работает Helm.

Как устроен Helm

Հայտ aplikasi-ի փոփոխությունները վերջին թողարկումից հետո կարող է պարզել Helm-ը:

• Kubernetes-ում ծածկված aplikasi-ով;
• նոր values.yaml և նոր հաշիվով;
• Helm-ի ներսի տեղեկություններով թողարկումների մասին.

Ավելի հետաքրքրասիրողների համար: Որտեղ է Helm-ը պահում ներսի տեղեկությունները թողարկումների մասին?Առաջին հերթին կատարելով հրամանը helm history, մենք կստանանք ամբողջ տեղեկությունը, որը վերաբերում է տարբերակի վերաբերյալ, որը տեղադրվել է Helm-ի միջոցով.

Ամեն դեպքում, կա ավելի մանրամասն տեղեկություն ուղարկված ձևերի և արժեքների մասին: Մենք կարող ենք այն պահանջել:

Helm-ի երկրորդ տարբերակում, այդ տեղեկությունը գտնվում է այն նույն namespaces-ում, որտեղ տեղադրված է Tiller-ը (նույն մեքենաների համակարգում դա `kube-system` է), `OWNER=TILLER` նշումով ConfigMap-ում:

Երրորդ Helm-ի ժամանակ, տեղեկությունը տեղափոխվել է գաղտնիքների մեջ, իսկ այն գտնվում է այն նույն namespaces-ում, որտեղ աշխատում է aplikasi-ը: Սա հնարավորություն տվեց միաժամանակ բազմաթիվ aplikasi-ներ գործարկել նույն քննության անունով տարբեր namespaces–ներում: Երկրորդ տարբերակում դա ախտաբեր սենսացիա էր, երբ namespaces-ը առանձնացված էին, բայց կարող էին փոխազդել միմյանց հետ.

Երկրորդ Helm-ը, երբ փորձում է հասկանալ, արդյոք թարմացում է անհրաժեշտ, օգտագործում է միայն երկու տեղեկարանքներով աղբյուր: Ինձ տրված ներկայը ու ներսի տեղեկություններ ախոյանների մասին, որոնք գտնվում են ConfigMap-ում.

Թեստ նավահանգիստը ստանում է երեք կողմանի միացում: Ավելին, վերջին տեղեկություններից բացի հաշվի է առնում նաև այն aplikasi-ը, որն այժմ աշխատում է Kubernetes-ում.

Այս պատճառով, հին Helm-ը ոչինչ չի անի, քանի որ հաշվի չի առնում կրող տեղեկությունները, սակայն Helm 3-ը կստանա փոփոխությունները և նոր aplikasi կներդնի.

Միջոց 5. Օգտագործեք բանալին՝ --recreate-pods

Հրամանը --recreate-pods կարող է հասնել այն, ինչ սկզբում նախատեսվում էր` օգտագործելով բանալին: Եկեք նայենք ձեռնարկներին և գտնում ենք անհրաժեշտ բանալին: Ամենագլխավոր իմաստով բանալին ամենաանհարմար է: Այնուամենայնիվ, խոսակցային անվանմամբ, վարքը տարբեր է սպասվողից: Force-ով թարմացրած հավելվածը իրականում նախատեսված է FAILED վիճակում գտնվող թողարկման վերականգնման համար: Եթե չի օգտագործվի այդ բանալին, ապա sequential հրամաններն առաջին կարգով պետք է կատարել՝Կոնտեյներով կրկին կբացվեն և, համաձայն `imagePullPolicy: Always` քաղաքականության` վերջին թեգը (այս մասին վերևում նշվածում), Kubernetes-ը կներբեռնի և կմեկնարկի նոր ապրանքի տարբերակը: Դա չի լինելու ամենաէֆեկտիվ կերպով: Խիստ կդահանա բոլոր հին ծրագրերից և կսկսի նորերը: Դադարեցման ժամանակ համակարգը չի գործի, օգտվողները կկարողանան դժվարություն ունենալ:

Վերջապես, Kubernetes-ում նման խնդիր նույնպես գտնվել է երկար ժամանակ: Եվ ահա, 4 տարվա անցումից հետո, Խնդիր, խնդիրը լուծվել էր և սկսած 1.15 Kubernetes-ի տարբերակից, հնարավորություն է հայտնվում ավտոմատացված վերագործարկել pods-ը.

Helm-ը պարզապես փակել է բոլոր aplikasi-ները և համահայեցված նոր կոնտեյներներ է սկսել: Արդյունաբերական պայմաններում այսպես անել չի կարելի, որպեսզի չհայտնի խնդիրներ: Դա անհրաժեշտ է միայն զարգացման կարիքների համար, ինչը կարելի է իրականացնել միայն փուլային միջավայրերում.

Ինչպես թարմացնել aplikasi-ի տարբերակը Helm-ի միջոցով?

Մենք գնալու ենք փոփոխել Helm-ին ուղարկվող արժեքները: Համապատասխանաբար, այս արժեքներն այն են, որոնք տեղադրվում են պատկերանշանի տեղում: «latest» – ի դեպքում, որը հաճախ օգտագործվում է արտադրության դուրս գալուց հեռու, փոփոխվող տեղեկատվությունը կլինի անգնահատելի, որը Kubernetes-ի համար անօգուտ է, բայց Helm-ի համար ծառայելու է որպես ազդանշան, որ անհրաժեշտ է թարմացնել ծրագիրը: Գերադասված լրացման տարբերակները:

1. Պահանջված արժեք Standart ֆունկցիայի օգնությամբ՝ {{ randAlphaNum 6 }}.
   Կան մանրամասներ՝ յուրաքանչյուր despleire-ից հետո, երբ օգտագործվում է այս փոփոխականը պարունակող անցեղ վերանում», այս անոտացիայի արժեքը միանշանակ կլինի, և Helm-ը կհասկանա, որ փոփոխություններ կան: Հետևաբար, մենք միշտ վերնականորոգելու ենք ծրագիրը, նույնիսկ եթե դրա տարբերակը չի փոխվել: Սա կարևոր չէ, քանի որ կանգնեցում չի լինի, սակայն դա զզվելի է:
2. Ներդրեք ներկա ամսաթիվն ու ժամը — {{ .Release.Date }}.
   Այս տարբերակը նման է պահանջված արժեքին, սակայն ունի մշտապես յուրահատուկ փոփոխական:
3. Լավագույն տարբերակը՝ օգտագործել հսկողության գումարները. Սա պատկերանշանի SHA-ն կամ հենց վերջին կոմիտից բխող SHA-ն՝ {{ .Values.sha }}.
   Այս գումարները պետք է հաշվարկվեն և ուղարկվեն Helm հաճախորդին, օրինակ, Jenkins-ում: Եթե ծրագիրը փոփոխություն է ունեցել, ապա նաև հսկողության գումարը կփոխվի: Նշանակում է, որ Helm-ը կթարմացնի ծրագիրը միայն անհրաժեշտ դեպքում:

Եղած բոլոր փորձերի արդյունքների հաղորդում

• Helm-ը փոփոխությունները կատարում է ամենաքիչ ներթափանցիկ կերպով, հետևաբար ծրագրի մակարդակում պատկերանշանի փոփոխությունն չի առաջացնել թարմացում: Կրթական հրահանգ իրականացնելուց հետո ոչինչ չի լինի:
• Կատալոգ Եկեք նայենք ձեռնարկներին և գտնում ենք անհրաժեշտ բանալին: Ամենագլխավոր իմաստով բանալին ամենաանհարմար է: Այնուամենայնիվ, խոսակցային անվանմամբ, վարքը տարբեր է սպասվողից: Force-ով թարմացրած հավելվածը իրականում նախատեսված է FAILED վիճակում գտնվող թողարկման վերականգնման համար: Եթե չի օգտագործվի այդ բանալին, ապա sequential հրամաններն առաջին կարգով պետք է կատարել՝ օգտագործվում է խնդիր հանդիսացող թողարկումները վերականգնելու համար և չի կապված պարտադիր թարմացման հետ:
• Կատալոգ --recreate-pods առանձնակի թարմացնելու է ծրագրերը, բայց դա կանի վանդալային կերպով՝ անհապաղ անջատելով բոլոր կոնտեյները: Սա վնասելու է օգտվողներին, արտադրությունում դա չի լինում:
• Դիրքավորել սահմանափակումներ անմիջապես Kubernetes ավազանում՝ kubectl edit չի կարելի. մենք կխախտենք համախմբվածությունը, և վարքը կտրամադրվի տարբեր տարբերակներում:
• Նոր Helm-ի տարբերակի դուրս գալով շատ մանրամասներ են առաջացել: Issues Helm-ի ռեպոզիտորիայում բացատրության լեզվով նկարագրված են, դրանք կօգնեն հասկանալ մանրամասները:
• Փոփոխվող անոտացիայի ավելացումը անցեղը ավելի ճկուն կդարձնի: Սա թույլ կտա հաղորդավառնալ ծրագիրը ճիշտ՝ առանց կանգնեցման:

Ուղեկցություն ոլորտների վրա "միություն ու ողջ աշխարհում": Պարզեք ձեռնարկը օգտագործելուց առաջ, այլ ոչ թե հետո: Միայն լիարժեք տեղեկություններով կարող եք ավելացնել կայացած համակարգեր և երջանկացնել օգտվողներին:

Այլ հղումներ թեմայով:

1. Հանդիպում Helm 3
2. Helm-ի պաշտոնական կայք
3. Helm-ի ռեպոզիտոր ֆիլմ GitHub-ում
4. 25 օգտակար Kubernetes գործիքներ: Տեղադրելու և կառավարելու համար

Այս զեկույցը առաջին անգամ հնչեց @Kubernetes Conference Mail.ru Cloud Solutions-ի կողմից։ Գործողություն վիդեո այլ ներկայացումների և միացեք միջոցառումների հայտարարություններին Telegram-ում Kubernetes-ի շուրջ Mail.ru Group-ում.

Ընտանիք: habr.com