Ես Դմիտրի Սուգրոբովն եմ, ես ծրագրավորող եմ Leroy Merlin-ում: Այս հոդվածում ես ձեզ կասեմ, թե ինչու է անհրաժեշտ Helm-ը, ինչպես է այն հեշտացնում աշխատել Kubernetes-ի հետ, ինչ է փոխվել երրորդ տարբերակում և ինչպես օգտագործել այն՝ արտադրության մեջ հավելվածները թարմացնելու համար՝ առանց ընդհատումների:
Սա ամփոփում է՝ հիմնված համաժողովում ունեցած ելույթի վրա by — եթե չեք ուզում կարդալ, դիտե՛ք տեսանյութը։
Ինչու ենք մենք օգտագործում Kubernetes-ը արտադրության մեջ
Leroy Merlin-ը Ռուսաստանում և Եվրոպայում DIY մանրածախ շուկայի առաջատարն է: Մեր ընկերությունն ունի ավելի քան հարյուր ծրագրավորող, 33 ներքին աշխատող և հիպերմարկետներ և կայք այցելող հսկայական թվով մարդիկ: Նրանց բոլորին ուրախացնելու համար մենք որոշեցինք հետևել ոլորտի ստանդարտ մոտեցումներին: Մշակել նոր հավելվածներ՝ օգտագործելով միկրոսերվիսային ճարտարապետություն; օգտագործել բեռնարկղեր՝ միջավայրերը մեկուսացնելու և պատշաճ առաքում ապահովելու համար. և նվագախմբի համար օգտագործիր Kubernetes-ը: Նվագավորների օգտագործման գինը արագորեն էժանանում է. շուկայում աճում է տեխնոլոգիային տիրապետող ինժեներների թիվը, և մատակարարները հայտնվում են՝ առաջարկելով Kubernetes-ը որպես ծառայություն:
Այն ամենը, ինչ անում է Kubernetes-ը, իհարկե, կարելի է անել այլ կերպ, օրինակ՝ ծածկելով որոշ Ջենկիններ և docker-compose-ը սցենարներով, բայց ինչո՞ւ բարդացնել կյանքը, եթե կա պատրաստի և հուսալի լուծում: Դրա համար մենք եկանք Kubernetes և արդեն մեկ տարի է այն օգտագործում ենք արտադրության մեջ։ Ներկայումս մենք ունենք քսանչորս Kubernetes կլաստերներ, որոնցից ամենահինն ավելի քան մեկ տարեկան է՝ մոտ երկու հարյուր պատիճով:
Մեծ YAML ֆայլերի անեծքը Kubernetes-ում
Kubernetes-ում միկրոծառայություն գործարկելու համար մենք կստեղծենք առնվազն հինգ YAML ֆայլ՝ Deployment, Service, Ingress, ConfigMap, Secrets-ի համար և կուղարկենք դրանք կլաստերին: Հաջորդ հավելվածի համար կգրենք նույն փաթեթը ջամբերի հետ, երրորդի հետ կգրենք ևս մեկը և այլն։ Եթե փաստաթղթերի քանակը բազմապատկենք միջավայրերի քանակով, ապա արդեն հարյուրավոր ֆայլեր կստանանք, և դա դեռ հաշվի չի առնվում դինամիկ միջավայրերը։
Ադամ Ռիզը, Հելմի հիմնական պահպանողը, ներկայացրեց «», որն ունի հետևյալ տեսքը.
- Պատճենել YAML - պատճենել YAML ֆայլը:
- Կպցնել YAML - կպցնել այն:
- Fix Indents - ուղղել նահանջները:
- Կրկնել - նորից կրկնել:
Տարբերակն աշխատում է, բայց դուք պետք է բազմիցս պատճենեք YAML ֆայլերը: Այս ցիկլը փոխելու համար հայտնագործվեց Հելմը:
Ինչ է Helm-ը
Նախ, Հելմ - փաթեթի կառավարիչ, որն օգնում է ձեզ գտնել և տեղադրել ձեզ անհրաժեշտ ծրագրերը: Օրինակ, MongoDB-ն տեղադրելու համար հարկավոր չէ գնալ պաշտոնական կայք և ներբեռնել երկուականներ, պարզապես գործարկել հրամանը. helm install stable/mongodb.
Երկրորդ, Հելմ - կաղապարի շարժիչ, օգնում է պարամետրիզացնել ֆայլերը: Եկեք վերադառնանք Kubernetes-ում YAML ֆայլերի իրավիճակին: Ավելի հեշտ է գրել նույն YAML ֆայլը, դրան ավելացնել որոշ տեղապահեր, որոնց մեջ Helm-ը կփոխարինի արժեքները: Այսինքն, փայտամածների մեծ հավաքածուի փոխարեն կլինի մի շարք ձևանմուշներ, որոնցում անհրաժեշտ արժեքները կփոխարինվեն ճիշտ ժամանակին:
Երրորդ, Հելմ - տեղակայման վարպետ. Դրանով դուք կարող եք տեղադրել, հետ վերադարձնել և թարմացնել հավելվածները: Եկեք պարզենք, թե ինչպես դա անել:
Ինչպես օգտագործել Helm-ը ձեր սեփական հավելվածները տեղակայելու համար
Եկեք տեղադրենք Helm հաճախորդը ձեր համակարգչում, հետևելով պաշտոնականին . Հաջորդը, մենք կստեղծենք YAML ֆայլերի մի շարք: Հատուկ արժեքներ նշելու փոխարեն, մենք կթողնենք տեղապահներ, որոնք Հելմը լրացնելու է տեղեկատվություն ապագայում: Նման ֆայլերի հավաքածուն կոչվում է Helm chart: Այն կարող է ուղարկվել Helm կոնսոլի հաճախորդին երեք եղանակով.
- նշեք կաղապարներով թղթապանակ;
- փաթեթավորեք արխիվը .tar-ի մեջ և մատնացույց արեք այն;
- դրեք ձևանմուշը հեռավոր պահոցում և հղում ավելացրեք պահեստին 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. Պարզության համար երկու հրամանների փոխարեն կարող եք գործարկել հրամանը upgrade լրացուցիչ բանալիով --install. Երբ առաջին անգամ կատարվի, Helm-ը հրաման կուղարկի թողարկումը տեղադրելու համար և այն կթարմացնի ապագայում:
helm upgrade --install bestapp --values values.yaml lmru/bestchart
Helm-ի հետ հավելվածի նոր տարբերակների տեղակայման որոգայթները
Պատմության այս պահին ես հանդիսատեսի հետ խաղում եմ «Ով է ուզում դառնալ միլիոնատեր», և մենք պարզում ենք, թե ինչպես Հելմին ստիպել թարմացնել հավելվածի տարբերակը: .
Երբ ես սովորում էի, թե ինչպես է աշխատում Helm-ը, ինձ զարմացրեց տարօրինակ պահվածքը, երբ փորձում էի թարմացնել գործող հավելվածների տարբերակները: Ես թարմացրեցի հավելվածի կոդը, նոր պատկեր վերբեռնեցի Docker ռեեստրում, ուղարկեցի տեղակայման հրամանը, և ոչինչ տեղի չունեցավ: Ստորև ներկայացված են հավելվածները թարմացնելու մի քանի ոչ լիովին հաջող եղանակներ: Նրանցից յուրաքանչյուրն ավելի մանրամասն ուսումնասիրելով՝ սկսում ես հասկանալ գործիքի ներքին կառուցվածքը և այս ոչ ակնհայտ վարքի պատճառները։
Մեթոդ 1. Մի փոխեք տեղեկատվությունը վերջին գործարկումից հետո
Ինչպես ձայնը Հելմ, «Kubernetes գծապատկերները կարող են լինել մեծ և բարդ, ուստի Հելմը փորձում է որևէ բանի շատ չդիպչել»: Հետևաբար, եթե դուք թարմացնեք հավելվածի պատկերի վերջին տարբերակը դոկերի ռեեստրում և գործարկեք հրամանը helm upgrade, ապա ոչինչ չի լինի։ Հելմը կմտածի, որ ոչինչ չի փոխվել, և կարիք չկա Kubernetes-ին հրաման ուղարկել հավելվածը թարմացնելու համար։
Այստեղ և ներքևում վերջին պիտակը ցուցադրվում է բացառապես որպես օրինակ: Երբ նշեք այս պիտակը, Kubernetes-ը ամեն անգամ կներբեռնի պատկերը դոկերի ռեեստրից՝ անկախ imagePullPolicy պարամետրից: Արտադրության վերջին տարբերակի օգտագործումը անցանկալի է և առաջացնում է կողմնակի բարդություններ:
Մեթոդ 2. Թարմացրեք LABEL-ը պատկերում
Ինչպես գրված է նույնում , «Helm-ը միայն կթարմացնի հավելվածը, եթե այն փոխվել է վերջին թողարկումից հետո»: Դրա համար տրամաբանական տարբերակ է թվում LABEL-ի թարմացումը հենց դոկերի պատկերում: Այնուամենայնիվ, Հելմը չի նայում հավելվածի պատկերներին և պատկերացում չունի դրանցում որևէ փոփոխության մասին: Համապատասխանաբար, պատկերի պիտակները թարմացնելիս Helm-ը չի իմանա դրանց մասին, և հավելվածի թարմացման հրամանը չի ուղարկվի Kubernetes-ին:
Մեթոդ 3. Օգտագործեք բանալի --force
Եկեք դիմենք ձեռնարկներին և փնտրենք անհրաժեշտ բանալին: Բանալին առավել իմաստալից է --force. Չնայած ակնհայտ անվանմանը, վարքագիծը տարբերվում է սպասվածից: Հավելվածի թարմացում պարտադրելու փոխարեն, դրա իրական նպատակը FAILED կարգավիճակում գտնվող թողարկումը վերականգնելն է: Եթե դուք չեք օգտագործում այս բանալին, դուք պետք է կատարեք հրամանները հաջորդաբար helm delete && helm install --replace. Փոխարենը առաջարկվում է օգտագործել բանալին --force, որն ավտոմատացնում է այս հրամանների հաջորդական կատարումը։ Լրացուցիչ տեղեկություններ այս . Հելմին ասելու համար թարմացնել հավելվածի տարբերակը, ցավոք, այս բանալին չի աշխատի։
Մեթոդ 4. Փոխեք պիտակները անմիջապես Kubernetes-ում
Պիտակի թարմացում անմիջապես կլաստերի մեջ՝ օգտագործելով հրամանը kubectl edit - վատ գաղափար. Այս գործողությունը կհանգեցնի գործող հավելվածի և սկզբնապես տեղակայման ուղարկված տեղեկատվության անհամապատասխանության: Helm-ի պահվածքը տեղակայման ժամանակ այս դեպքում տարբերվում է իր տարբերակից՝ Helm 2-ը ոչինչ չի անի, իսկ Helm 3-ը կտեղակայի հավելվածի նոր տարբերակը։ Հասկանալու համար, թե ինչու, դուք պետք է հասկանաք, թե ինչպես է աշխատում Հելմը:
Ինչպե՞ս է աշխատում Հելմը:
Որոշելու համար, թե արդյոք հավելվածը փոխվել է վերջին թողարկումից հետո, Helm-ը կարող է օգտագործել.
- գործարկվող հավելված Kubernetes-ում;
- նոր արժեքներ.yaml և ընթացիկ աղյուսակ;
- Հելմի ներքին թողարկման տեղեկատվությունը.
Ավելի հետաքրքրասերների համար. որտե՞ղ է Հելմը պահում թողարկումների մասին ներքին տեղեկությունները:Հրամանի կատարմամբ helm history, մենք կստանանք բոլոր տեղեկությունները Helm-ի միջոցով տեղադրված տարբերակների մասին:
Կա նաև մանրամասն տեղեկատվություն ուղարկված կաղապարների և արժեքների մասին։ Մենք կարող ենք պահանջել.
Helm-ի երկրորդ տարբերակում այս տեղեկատվությունը գտնվում է նույն անվանատարածքում, որտեղ աշխատում է Tiller-ը (կանխադրված kube-համակարգ), ConfigMap-ում, որը նշված է «OWNER=TILLER» պիտակով.
Երբ հայտնվեց Helm-ի երրորդ տարբերակը, տեղեկատվությունը տեղափոխվեց գաղտնիքներ և նույն անվանատարածք, որտեղ գործում էր հավելվածը: Դրա շնորհիվ հնարավոր դարձավ միաժամանակ գործարկել մի քանի հավելվածներ տարբեր անվանատարածքներում՝ թողարկման նույն անվանումով։ Երկրորդ տարբերակում դա լուրջ գլխացավանք էր, երբ անունների տարածքները մեկուսացված են, բայց կարող են ազդել միմյանց վրա:
Երկրորդ Helm-ը, երբ փորձում է հասկանալ, թե արդյոք անհրաժեշտ է թարմացում, օգտագործում է տեղեկատվության միայն երկու աղբյուր՝ այն, ինչ տրամադրվում է նրան հիմա, և թողարկումների մասին ներքին տեղեկատվություն, որը գտնվում է ConfigMap-ում:
Երրորդ Helm-ը օգտագործում է եռակողմ միաձուլման ռազմավարություն. բացի այդ տեղեկատվությունից, այն նաև հաշվի է առնում հավելվածը, որն աշխատում է հենց հիմա Kubernetes-ում:
Այդ իսկ պատճառով Helm-ի հին տարբերակը ոչինչ չի անի, քանի որ հաշվի չի առնում հավելվածի տեղեկատվությունը կլաստերի մեջ, սակայն Helm 3-ը կստանա փոփոխությունները և կուղարկի նոր հավելվածը տեղակայման:
Մեթոդ 5. Օգտագործեք --recreate-pods անջատիչը
Բանալով --recreate-pods դուք կարող եք հասնել նրան, ինչի սկզբում պլանավորել էիք հասնել բանալին --force. Կոնտեյներները կվերագործարկվեն և, ըստ imagePullPolicy. Միշտ քաղաքականություն վերջին պիտակի համար (այս մասին ավելին վերևի ծանոթագրության մեջ), Kubernetes-ը կներբեռնի և կգործարկի պատկերի նոր տարբերակը: Դա չի արվի լավագույն ձևով. առանց հաշվի առնելու StrategyType of deployment-ը, այն կտրուկ կանջատի բոլոր հին հավելվածների օրինակները և կսկսի գործարկել նորերը: Վերագործարկման ժամանակ համակարգը չի աշխատի, կտուժեն օգտատերերը։
Բուն Kubernetes-ում նման խնդիր նույնպես երկար ժամանակ կար։ Իսկ հիմա՝ բացումից 4 տարի անց Խնդիրը շտկվել է, և սկսած Kubernetes-ի 1.15 տարբերակից, հայտնվում է pods-ի վերագործարկման հնարավորությունը։
Helm-ը պարզապես անջատում է բոլոր հավելվածները և մոտակայքում գործարկում նոր կոնտեյներներ: Դուք չեք կարող դա անել արտադրության մեջ, որպեսզի չառաջացնեք հավելվածի խափանում: Սա անհրաժեշտ է միայն զարգացման կարիքների համար և կարող է իրականացվել միայն բեմական միջավայրում:
Ինչպե՞ս թարմացնել հավելվածի տարբերակը՝ օգտագործելով Helm-ը:
Մենք կփոխենք Helm-ին ուղարկված արժեքները: Սովորաբար, դրանք արժեքներ են, որոնք փոխարինվում են պատկերի պիտակի փոխարեն: Վերջինի դեպքում, որը հաճախ օգտագործվում է անարդյունավետ միջավայրերի համար, փոփոխվող տեղեկատվությունը անոտացիա է, որն անօգուտ է հենց Kubernetes-ի համար, իսկ Helm-ի համար այն ազդանշան կլինի հավելվածը թարմացնելու անհրաժեշտության համար։ Անոտացիայի արժեքը լրացնելու տարբերակներ.
- Պատահական արժեք օգտագործելով ստանդարտ գործառույթը -
{{ randAlphaNum 6 }}.
Կա մի նախազգուշացում. յուրաքանչյուր տեղակայումից հետո նման փոփոխականով գծապատկեր օգտագործելով, անոտացիայի արժեքը եզակի կլինի, և Հելմը կենթադրի, որ փոփոխություններ կան: Ստացվում է, որ մենք միշտ կվերագործարկենք հավելվածը, նույնիսկ եթե չենք փոխել դրա տարբերակը։ Սա կարևոր չէ, քանի որ պարապուրդ չի լինի, բայց դեռ տհաճ է: - Կպցնել հոսանքը ամսաթիվը և ժամը -
{{ .Release.Date }}.
Տարբերակը նման է մշտական եզակի փոփոխական ունեցող պատահական արժեքին: - Ավելի ճիշտ միջոց օգտագործելն է չեկային գումարներ. Սա պատկերի SHA-ն է կամ git-ում վերջին կատարման SHA-ն.
{{ .Values.sha }}.
Նրանք պետք է հաշվվեն և ուղարկվեն Helm հաճախորդին զանգող կողմում, օրինակ՝ Ջենկինսում: Եթե դիմումը փոխվել է, ապա ստուգման գումարը կփոխվի: Հետևաբար, Helm-ը միայն անհրաժեշտության դեպքում կթարմացնի հավելվածը:
Ամփոփենք մեր փորձերը
- Helm-ը փոփոխություններ է կատարում ամենաքիչ ինվազիվ ձևով, ուստի Docker Registry-ում հավելվածի պատկերի մակարդակի ցանկացած փոփոխություն չի հանգեցնի թարմացման. հրամանը կատարելուց հետո ոչինչ չի պատահի:
- Բանալին
--forceօգտագործվում է խնդրահարույց թողարկումները վերականգնելու համար և կապված չէ հարկադիր թարմացումների հետ: - Բանալին
--recreate-podsուժով կթարմացնի հավելվածները, բայց դա կանի վանդալային եղանակով. կտրուկ կանջատի բոլոր բեռնարկղերը: Օգտագործողները կտուժեն դրանից, դուք չպետք է դա անեք արտադրության մեջ: - Ուղղակի փոփոխություններ կատարեք Kubernetes կլաստերում՝ օգտագործելով հրամանը
kubectl editմի՛. մենք կխախտենք հետևողականությունը, և վարքագիծը կտարբերվի՝ կախված Helm-ի տարբերակից: - Helm-ի նոր տարբերակի թողարկմամբ ի հայտ են եկել բազմաթիվ նրբերանգներ։ Helm շտեմարանի խնդիրները նկարագրված են պարզ լեզվով, դրանք կօգնեն ձեզ հասկանալ մանրամասները:
- Գծապատկերում խմբագրվող անոտացիա ավելացնելը այն ավելի ճկուն կդարձնի: Սա թույլ կտա ճիշտ ձևակերպել հավելվածը, առանց ընդհատումների:
«Համաշխարհային խաղաղության» միտք, որն աշխատում է կյանքի բոլոր ոլորտներում. կարդալ հրահանգները օգտագործելուց առաջ, ոչ թե հետո: Միայն ամբողջական տեղեկատվության դեպքում հնարավոր կլինի կառուցել հուսալի համակարգեր և ուրախացնել օգտատերերին։
Այլ հարակից հղումներ.
Այս զեկույցն առաջին անգամ ներկայացվել է ժ Mail.ru Cloud Solutions-ի կողմից: Նայել այլ ներկայացումներ և բաժանորդագրվեք իրադարձությունների հայտարարություններին Telegram-ում .
Source: www.habr.com