Հաջորդ ներկայացնում ենք նրա ավագ եղբորը. . Սա բաց կոդով նախագիծ է, որն օգտագործվում է Kubernetes կլաստերի մեջ համակարգի բաղադրիչները տեղադրելու համար, որոնք կարելի է անվանել հավելումներ:
Ինչո՞ւ ընդհանրապես հավելումներ:
Գաղտնիք չէ, որ Kubernetes-ը պատրաստի բոլորը մեկում արտադրանք չէ, և «մեծահասակների» կլաստեր ստեղծելու համար ձեզ անհրաժեշտ կլինեն տարբեր հավելումներ։ Addon-operator-ը կօգնի ձեզ տեղադրել, կարգավորել և թարմացնել այս հավելումները:
Կլաստերում լրացուցիչ բաղադրիչների անհրաժեշտությունը բացահայտված է գործընկերներ . Մի խոսքով, Kubernetes-ի հետ կապված իրավիճակն այս պահին այնպիսին է, որ պարզ «play around» տեղադրման համար կարող եք դուրս գալ բաղադրիչներից, մշակողների և փորձարկման համար կարող եք ավելացնել Ingress, բայց ամբողջական տեղադրման համար, որի մասին կարող եք ասել «ձեր արտադրությունը պատրաստ է», դուք պետք է ավելացնեք տասնյակ տարբեր հավելումներով. ինչ-որ բան մոնիտորինգի համար, ինչ-որ բան գրանցման համար, մի մոռացեք մուտքի և սերտի մենեջերի մասին, ընտրեք հանգույցների խմբեր, ավելացրեք ցանցային քաղաքականություն, սեզոն: sysctl և pod autoscaler կարգավորումներով...
Որո՞նք են նրանց հետ աշխատելու առանձնահատկությունները:
Ինչպես ցույց է տալիս պրակտիկան, հարցը չի սահմանափակվում մեկ տեղադրմամբ: Կլաստերի հետ հարմարավետ աշխատելու համար հավելումները պետք է թարմացվեն, անջատվեն (հեռացվեն կլաստերից), և դուք կցանկանաք մի քանիսը փորձարկել նախքան դրանք արտադրական կլաստերում տեղադրելը:
Այսպիսով, միգուցե Ansible-ը բավական կլինի այստեղ: Միգուցե. Բայց Ընդհանուր առմամբ, լիարժեք հավելումները չեն ապրում առանց պարամետրերի. Այս կարգավորումները կարող են տարբերվել՝ կախված կլաստերային տարբերակից (aws, gce, azure, bare-metal, do, ...): Որոշ կարգավորումներ հնարավոր չէ նախապես նշել, դրանք պետք է ձեռք բերվեն կլաստերից: Եվ կլաստերը ստատիկ չէ. որոշ պարամետրերի համար դուք պետք է վերահսկեք փոփոխությունները: Եվ այստեղ Ansible-ն արդեն բացակայում է. ձեզ անհրաժեշտ է ծրագիր, որն ապրում է կլաստերի մեջ, այսինքն. Kubernetes օպերատոր.
Նրանք, ովքեր փորձեցին դա աշխատավայրում , նրանք կասեն, որ հավելումների տեղադրման և թարմացման խնդիրները և մոնիտորինգի կարգավորումները կարող են ամբողջությամբ լուծվել՝ օգտագործելով shell-օպերատորի համար: Դուք կարող եք գրել սցենար, որը կկատարի պայմանական kubectl apply և վերահսկել, օրինակ, ConfigMap-ը, որտեղ կպահվեն կարգավորումները: Սա մոտավորապես այն է, ինչ իրականացվում է addon-operator-ում:
Ինչպե՞ս է դա կազմակերպվում հավելյալ օպերատորում:
Նոր լուծում ստեղծելիս մենք ելնում ենք հետևյալ սկզբունքներից.
- Հավելյալ տեղադրողը պետք է աջակցի ձևանմուշ և դեկլարատիվ կոնֆիգուրացիա. Մենք կախարդական սցենարներ չենք ստեղծում, որոնք տեղադրում են հավելումներ: Addon-օպերատորն օգտագործում է Helm-ը հավելումներ տեղադրելու համար: Տեղադրելու համար դուք պետք է ստեղծեք գծապատկեր և ընտրեք այն արժեքները, որոնք կօգտագործվեն կազմաձևման համար:
- Կարգավորումները կարող են լինել առաջացնել տեղադրման ժամանակ, նրանք կարող են ստանալ կլաստերիցԿամ ստանալ թարմացումներ, կլաստերի ռեսուրսների մոնիտորինգ: Այս գործողությունները կարող են իրականացվել կեռիկների միջոցով:
- Կարգավորումները կարող են լինել պահել կլաստերի մեջ. Կլաստերում կարգավորումները պահելու համար ստեղծվում է ConfigMap/addon-օպերատոր, և Addon-օպերատորը վերահսկում է այս ConfigMap-ի փոփոխությունները: Addon-օպերատորը կեռիկներին հասանելի է դարձնում կարգավորումները՝ օգտագործելով պարզ կոնվենցիաներ:
- Հավելումը կախված է պարամետրերից. Եթե կարգավորումները փոխվել են, ապա Addon-օպերատորը գլորում է Helm աղյուսակը նոր արժեքներով: Մենք անվանեցինք Helm գծապատկերի համադրությունը, դրա արժեքները և կեռերը մոդուլ (տե՛ս ստորև՝ լրացուցիչ մանրամասների համար):
- Բեմականացում. Կախարդական թողարկման սցենարներ չկան: Թարմացման մեխանիզմը նման է սովորական հավելվածին՝ հավաքել հավելումներ և հավելումներ օպերատորներ պատկերի մեջ, նշել դրանք և տարածել դրանք:
- Արդյունքների վերահսկում. Addon-օպերատորը կարող է ապահովել Պրոմեթևսի չափումներ:
Ի՞նչ է լիցքավորումը հավելյալ օպերատորում:
Հավելում կարելի է համարել այն ամենը, ինչը նոր գործառույթներ է ավելացնում կլաստերին։ Օրինակ, Ingress-ի տեղադրումը հավելման հիանալի օրինակ է: Սա կարող է լինել ցանկացած օպերատոր կամ վերահսկիչ իր սեփական CRD-ով` պրոմեթևս-օպերատոր, սերտ-մենեջեր, kube-վերահսկիչ-մենեջեր և այլն: Կամ ինչ-որ փոքր, բայց ավելի հեշտ օգտագործման համար, օրինակ՝ գաղտնի պատճենահանող սարք, որը պատճենում է ռեեստրի գաղտնիքները նոր անունների տարածքներում, կամ sysctl թյուներ, որը կարգավորում է sysctl պարամետրերը նոր հանգույցների վրա:
Հավելումներ իրականացնելու համար Addon-օպերատորը տրամադրում է մի քանի հասկացություններ.
- Սաղավարտի աղյուսակ օգտագործվում է կլաստերի մեջ տարբեր ծրագրեր տեղադրելու համար, օրինակ՝ Prometheus, Grafana, nginx-ingress: Եթե պահանջվող բաղադրիչն ունի Helm աղյուսակ, ապա այն տեղադրելը Addon-օպերատորի միջոցով շատ պարզ կլինի:
- Արժեքների պահպանում. Սաղավարտի գծապատկերները սովորաբար ունեն շատ տարբեր պարամետրեր, որոնք կարող են փոխվել ժամանակի ընթացքում: Addon-օպերատորն աջակցում է այս կարգավորումների պահպանմանը և կարող է վերահսկել դրանց փոփոխությունները՝ նոր արժեքներով Helm աղյուսակը նորից տեղադրելու համար:
- Կեռիկներ գործարկվող ֆայլեր են, որոնք Addon-օպերատորն աշխատում է իրադարձությունների վրա և որոնք մուտք են գործում արժեքների պահեստ: Կեռիկը կարող է վերահսկել կլաստերի փոփոխությունները և թարմացնել արժեքների պահեստում գտնվող արժեքները: Նրանք. Օգտագործելով կեռիկներ՝ դուք կարող եք բացահայտումներ կատարել՝ գործարկման ժամանակ կամ ըստ ժամանակացույցի կլաստերից արժեքներ հավաքելու համար, կամ կարող եք շարունակական բացահայտումներ կատարել՝ հավաքելով արժեքներ կլաստերից՝ հիմնվելով կլաստերի փոփոխությունների վրա:
- Մոդուլ Helm աղյուսակի, արժեքների պահեստի և կեռիկների համադրություն է: Մոդուլները կարող են միացվել կամ անջատվել: Մոդուլի անջատումը նշանակում է ջնջել Helm աղյուսակի բոլոր թողարկումները: Մոդուլները կարող են իրենց դինամիկ կերպով միացնել, օրինակ, եթե իրեն անհրաժեշտ բոլոր մոդուլները միացված են կամ եթե հայտնաբերումը գտել է անհրաժեշտ պարամետրերը կեռիկներում, դա արվում է օժանդակ միացված սկրիպտի միջոցով:
- Գլոբալ կեռիկներ. Սրանք «ինքնուրույն» կեռիկներ են, դրանք ներառված չեն մոդուլների մեջ և մուտք ունեն դեպի գլոբալ արժեքների խանութ, որոնց արժեքները հասանելի են մոդուլների բոլոր կեռիկներին:
Ինչպե՞ս են այս մասերը միասին աշխատում: Դիտարկենք նկարը փաստաթղթից.
Աշխատանքի երկու սցենար կա.
- Գլոբալ կեռիկը գործարկվում է իրադարձության արդյունքում, օրինակ, երբ կլաստերի ռեսուրսը փոխվում է: Այս կեռիկը մշակում է փոփոխությունները և նոր արժեքները գրում համաշխարհային արժեքների խանութում: Addon-օպերատորը նկատում է, որ գլոբալ պահեստը փոխվել է և գործարկում է բոլոր մոդուլները: Յուրաքանչյուր մոդուլ, օգտագործելով իր կեռիկները, որոշում է, թե արդյոք այն պետք է միացվի և թարմացնի իր արժեքների պահեստը: Եթե մոդուլը միացված է, Addon-օպերատորը սկսում է Helm աղյուսակի տեղադրումը: Այս դեպքում Helm աղյուսակը հասանելի է արժեքներին մոդուլի պահեստից և գլոբալ պահեստից:
- Երկրորդ սցենարն ավելի պարզ է. մոդուլի կեռիկը գործարկվում է իրադարձությունից և փոխում արժեքները մոդուլի արժեքների պահեստում: Addon-օպերատորը նկատում է դա և գործարկում է Helm աղյուսակը թարմացված արժեքներով:
Հավելումը կարող է իրականացվել որպես մեկ առանձին կեռիկ, կամ որպես մեկ Helm աղյուսակ, կամ նույնիսկ որպես մի քանի կախյալ մոդուլներ - սա կախված է կլաստերում տեղադրվող բաղադրիչի բարդությունից և կազմաձևման ճկունության ցանկալի մակարդակից: Օրինակ, պահեստում () կա sysctl-tuner հավելում, որն իրականացվում է և՛ որպես պարզ մոդուլ՝ կեռիկով և ղեկի գծապատկերով, և՛ օգտագործելով արժեքների պահեստը, որը հնարավորություն է տալիս կարգավորումներ ավելացնել՝ խմբագրելով ConfigMap-ը:
Թարմացումների առաքում
Մի քանի խոսք բաղադրիչի թարմացումների կազմակերպման մասին, որոնք տեղադրում է Addon-օպերատորը:
Addon-operator-ը կլաստերի մեջ գործարկելու համար ձեզ հարկավոր է պատկեր ստեղծել հավելումներով կեռիկի և Helm աղյուսակի ֆայլերի տեսքով, ավելացրեք երկուական ֆայլ addon-operator և այն ամենը, ինչ ձեզ անհրաժեշտ է կեռիկների համար. bash, kubectl, jq, python և այլն: Այնուհետև այս պատկերը կարող է տարածվել կլաստերի մեջ՝ որպես սովորական հավելված, և, ամենայն հավանականությամբ, դուք կցանկանաք կազմակերպել պիտակավորման այս կամ այն սխեման: Եթե կան մի քանի կլաստերներ, կարող է հարմար լինել նույն մոտեցումը, ինչ հավելվածների դեպքում՝ նոր թողարկում, նոր տարբերակ, գնալ բոլոր կլաստերներին և ուղղել Pods-ի պատկերը: Այնուամենայնիվ, զգալի թվով կլաստերների տարածման դեպքում մեզ ավելի հարմար էր ալիքից ինքնաթարմացման հայեցակարգը:
Ահա թե ինչպես ենք մենք դա անում.
- Ալիքը, ըստ էության, նույնացուցիչ է, որը կարող է սահմանվել ցանկացածի վրա (օրինակ՝ dev/stage/ea/stable):
- Ալիքի անունը պատկերի պիտակն է: Երբ դուք պետք է թարմացնեք ալիքի թարմացումները, նոր պատկեր է հավաքվում և պիտակվում ալիքի անունով:
- Երբ գրանցամատյանում նոր պատկեր է հայտնվում, Addon-operator-ը վերագործարկվում է և գործարկվում նոր պատկերով:
Սա լավագույն փորձը չէ, ինչպես գրված է . Խորհուրդ չի տրվում դա անել, բայց մենք խոսում ենք սովորական հավելված, որն ապրում է նույն կլաստերում. Addon-operator-ի դեպքում հավելվածը շատ տեղակայումներ է, որոնք ցրված են կլաստերներում, և ինքնաթարմացումը շատ է օգնում և հեշտացնում կյանքը:
Ալիքներն օգնում են և փորձարկման մեջԵթե կա օժանդակ կլաստեր, կարող եք այն կարգավորել ալիքին stage և թարմացումները տեղադրեք դրա մեջ՝ նախքան այն ալիքներ ուղարկելը ea и stable. Եթե ալիքի վրա կլաստերի հետ ea սխալ է տեղի ունեցել, կարող եք փոխել այն stable, մինչդեռ այս կլաստերի հետ կապված խնդիրը ուսումնասիրվում է։ Եթե կլաստերը դուրս է բերվում ակտիվ աջակցությունից, այն անցնում է իր «սառեցված» ալիքին, օրինակ. freeze-2019-03-20.
Բացի կեռիկներն ու սաղավարտի գծապատկերները թարմացնելուց, ձեզ կարող է անհրաժեշտ լինել թարմացում և երրորդ կողմի բաղադրիչ. Օրինակ, դուք նկատեցիք մի սխալ պայմանական հանգույց-արտահանիչում և նույնիսկ հասկացաք, թե ինչպես կարելի է այն կարկատել: Հաջորդը, դուք բացեցիք PR-ը և սպասում եք նոր թողարկմանը՝ անցնելու բոլոր կլաստերներով և մեծացնել պատկերի տարբերակը։ Անվերջ չսպասելու համար կարող եք կառուցել ձեր հանգույց-արտահանողը և անցնել դրան՝ նախքան PR-ն ընդունելը։
Ընդհանուր առմամբ, դա կարելի է անել առանց Addon-օպերատորի, բայց Addon-operator-ի հետ հանգույց-արտահանիչ տեղադրելու մոդուլը տեսանելի կլինի մեկ պահեստում, ձեր պատկերը կառուցելու համար Dockerfile-ը կարող է պահվել հենց այնտեղ, այն ավելի հեշտ է դառնում բոլոր մասնակիցների համար: գործընթացը հասկանալու համար, թե ինչ է տեղի ունենում... Եվ եթե կան մի քանի կլաստերներ, ապա ավելի հեշտ է դառնում թե՛ փորձարկել ձեր PR-ը, թե՛ նոր տարբերակ ներկայացնելը:
Բաղադրիչների թարմացման այս կազմակերպությունը մեզ մոտ հաջողությամբ է աշխատում, բայց ցանկացած այլ հարմար սխեմա կարող է իրականացվել, ի վերջո այս դեպքում Addon-operator-ը պարզ երկուական ֆայլ է.
Ամփոփում
Addon-operator-ում ներդրված սկզբունքները թույլ են տալիս կառուցել թափանցիկ գործընթաց՝ կլաստերի մեջ հավելումներ ստեղծելու, փորձարկելու, տեղադրելու և թարմացնելու համար, որը նման է սովորական հավելվածների մշակման գործընթացներին:
Addon-օպերատորի համար մոդուլի ձևաչափով հավելումներ (Սեղանի գծապատկեր + կեռիկներ) կարող են հասանելի լինել հանրությանը: Մենք՝ «Ֆլանտ» ընկերությունս, նախատեսում ենք ամառվա ընթացքում հրապարակել մեր զարգացումները նման հավելումների տեսքով։ Միացեք զարգացմանը GitHub-ում (, ), փորձեք կատարել ձեր սեփական հավելումը հիման վրա и , սպասեք նորությունների Habré-ի և մեր կայքում !
PS
Կարդացեք նաև մեր բլոգում.
- «";
- «.
Source: www.habr.com