Օպերատոր Kubernetes-ում տվյալների բազայի կլաստերների կառավարման համար: Վլադիսլավ Կլիմենկո (Altinity, 2019)

Զեկույցը նվիրված է Kubernetes-ում օպերատորի ստեղծման, նրա ճարտարապետության և գործունեության հիմնական սկզբունքների նախագծման գործնական խնդիրներին:

Զեկույցի առաջին մասում կքննարկենք.

• ինչ է օպերատորը Kubernetes-ում և ինչու է դա անհրաժեշտ.
• ինչպես է օպերատորը պարզեցնում բարդ համակարգերի կառավարումը.
• ինչ կարող է և ինչ չի կարող անել օպերատորը:

Հաջորդը, եկեք անցնենք օպերատորի ներքին կառուցվածքի քննարկմանը: Եկեք քայլ առ քայլ նայենք օպերատորի ճարտարապետությանը և գործունեությանը: Դիտարկենք այն մանրամասն.

• օպերատորի և Kubernetes-ի փոխազդեցություն;
• ինչ գործառույթներ է ստանձնում օպերատորը և ինչ գործառույթներ է նա հանձնում Kubernetes-ին:

Եկեք նայենք Kubernetes-ում բեկորների և տվյալների բազայի կրկնօրինակների կառավարմանը:
Հաջորդը, մենք կքննարկենք տվյալների պահպանման խնդիրները.

• ինչպես աշխատել Persistent Storage-ի հետ օպերատորի տեսանկյունից.
• Տեղական պահեստի օգտագործման սխալները:

Զեկույցի վերջին մասում մենք կդիտարկենք կիրառման գործնական օրինակներ clickhouse-օպերատոր Amazon-ից կամ Google Cloud Service-ից: Զեկույցը հիմնված է ClickHouse-ի համար օպերատորի զարգացման և շահագործման փորձի օրինակի վրա:

Video:

Ես Վլադիսլավ Կլիմենկոն եմ։ Այսօր ես ուզում էի խոսել օպերատորի մշակման և շահագործման մեր փորձի մասին, և սա մասնագիտացված օպերատոր է տվյալների բազայի կլաստերների կառավարման համար: Օրինակ ClickHouse-օպերատոր ClickHouse կլաստերը կառավարելու համար:

Ինչու՞ մենք հնարավորություն ունենք խոսելու օպերատորի և ClickHouse-ի մասին:

• Մենք աջակցում և զարգացնում ենք ClickHouse-ը:
• Այս պահին մենք փորձում ենք կամաց-կամաց մեր ներդրումն ունենալ ClickHouse-ի զարգացման գործում։ Իսկ ClickHouse-ում կատարված փոփոխությունների ծավալով մենք երկրորդն ենք Yandex-ից հետո։
• Մենք փորձում ենք լրացուցիչ նախագծեր ստեղծել ClickHouse էկոհամակարգի համար։

Ես կցանկանայի ձեզ պատմել այս նախագծերից մեկի մասին։ Խոսքը ClickHouse-օպերատորի մասին է Kubernetes-ի համար:

Զեկույցումս կցանկանայի անդրադառնալ երկու թեմայի.

• Առաջին թեման այն է, թե ինչպես է աշխատում մեր ClickHouse տվյալների բազայի կառավարման օպերատորը Kubernetes-ում:
• Երկրորդ թեման այն է, թե ինչպես է աշխատում ցանկացած օպերատոր, այսինքն՝ ինչպես է այն համագործակցում Kubernetes-ի հետ:

Այնուամենայնիվ, այս երկու հարցերը հատվելու են իմ զեկույցի ողջ ընթացքում:

Ո՞վ կհետաքրքրի լսել այն, ինչ ես փորձում եմ պատմել:

• Այն առավել կհետաքրքրի նրանց, ովքեր շահագործում են օպերատորներ:
• Կամ նրանց համար, ովքեր ցանկանում են ստեղծել իրենցը, որպեսզի հասկանան, թե ինչպես է այն աշխատում ներքին, ինչպես է օպերատորը համագործակցում Kubernetes-ի հետ և ինչ որոգայթներ կարող են հայտնվել:

Լավագույնս հասկանալու համար, թե ինչ ենք մենք այսօր քննարկելու, լավ գաղափար է իմանալ, թե ինչպես է աշխատում Kubernetes-ը և ունենալ հիմնական ամպային ուսուցում:

Ինչ է ClickHouse-ը: Սա սյունակային տվյալների բազա է, որն ունի հատուկ առանձնահատկություններ՝ վերլուծական հարցումների առցանց մշակման համար: Եվ դա ամբողջովին բաց կոդով է:

Եվ մեզ համար կարևոր է իմանալ միայն երկու բան. Դուք պետք է իմանաք, որ սա տվյալների բազա է, ուստի այն, ինչ ես ձեզ կասեմ, կիրառելի կլինի գրեթե ցանկացած տվյալների բազայի համար: Եվ այն փաստը, որ ClickHouse DBMS-ը շատ լավ է չափվում, տալիս է գրեթե գծային մասշտաբայնություն: Եվ հետևաբար, կլաստերի վիճակը ClickHouse-ի համար բնական վիճակ է: Եվ մենք առավել շահագրգռված ենք քննարկել, թե ինչպես կարելի է սպասարկել ClickHouse կլաստերը Kubernetes-ում:

Ինչո՞ւ է նա պետք այնտեղ։ Ինչո՞ւ մենք չենք կարող ինքներս շարունակել այն շահագործել։ Իսկ պատասխանները մասամբ տեխնիկական են, մասամբ՝ կազմակերպչական։

• Գործնականում մենք ավելի ու ավելի ենք բախվում մի իրավիճակի, երբ խոշոր ընկերություններում գրեթե բոլոր բաղադրիչներն արդեն գտնվում են Kubernetes-ում: Տվյալների բազաները մնում են դրսում։
• Եվ գնալով հարց է առաջանում. «Կարո՞ղ է սա տեղադրվել ներսում»: Ուստի խոշոր ընկերությունները փորձում են հասնել կառավարման առավելագույն միավորման, որպեսզի արագ կարողանան կառավարել իրենց տվյալների պահեստները:
• Եվ սա հատկապես օգնում է, եթե ձեզ անհրաժեշտ է առավելագույն հնարավորություն՝ կրկնելու նույն բանը նոր վայրում, այսինքն՝ առավելագույն շարժունակություն:

Որքանո՞վ է դա հեշտ կամ դժվար: Դա, իհարկե, կարելի է ձեռքով անել: Բայց դա այնքան էլ պարզ չէ, քանի որ մենք ունենք ինքնին Kubernetes-ի կառավարման հավելյալ բարդություն, բայց միևնույն ժամանակ ClickHouse-ի առանձնահատկությունները գերագնահատված են: Եվ այսպիսի ագրեգացիա է ստացվում։

Եվ այս ամենը միասին տալիս է բավականին մեծ տեխնոլոգիաներ, որոնց կառավարումը դառնում է բավականին դժվար, քանի որ Kubernetes-ը գործի է դնում իր առօրյա խնդիրները, իսկ ClickHouse-ը` իր խնդիրները առօրյա շահագործման: Հատկապես, եթե մենք ունենք մի քանի ClickHouses, և մենք պետք է անընդհատ ինչ-որ բան անենք դրանցով:

Դինամիկ կոնֆիգուրացիայով, ClickHouse-ն ունի բավականին մեծ թվով խնդիրներ, որոնք մշտական ​​բեռ են ստեղծում DevOps-ի վրա.

• Երբ մենք ուզում ենք ինչ-որ բան փոխել ClickHouse-ում, օրինակ, ավելացնել կրկնօրինակ կամ բեկոր, ապա մենք պետք է կառավարենք կոնֆիգուրացիան:
• Այնուհետև փոխեք տվյալների սխեման, քանի որ ClickHouse-ն ունի հատուկ փոխանակման մեթոդ: Այնտեղ դուք պետք է շարեք տվյալների դիագրամը, կազմեք կազմաձևերը:
• Դուք պետք է կարգավորեք մոնիտորինգը:
• Տեղեկամատյանների հավաքում նոր բեկորների, նոր կրկնօրինակների համար:
• Հոգ տանել վերականգնման մասին.
• Եվ վերագործարկեք:

Սրանք սովորական առաջադրանքներ են, որոնց օգտագործումը ես իսկապես կցանկանայի ավելի հեշտ դարձնել:

Kubernetes-ը ինքնին լավ է օգնում շահագործման մեջ, բայց հիմնական համակարգի բաների վրա:

Kubernetes-ը լավ է հեշտացնում և ավտոմատացնում այնպիսի բաներ, ինչպիսիք են.

• Վերականգնում:
• Վերսկսել.
• Պահպանման համակարգի կառավարում.

Դա լավ է, դա ճիշտ ուղղություն է, բայց նա լիովին անտեղյակ է, թե ինչպես վարել տվյալների բազայի կլաստերը:

Մենք ուզում ենք ավելին, մենք ցանկանում ենք, որ ամբողջ տվյալների բազան աշխատի Kubernetes-ում:

Ես կցանկանայի ստանալ մի մեծ կախարդական կարմիր կոճակի պես մի բան, որը դուք սեղմում եք, և մի կլաստեր՝ առօրյա խնդիրներով, որոնք պետք է լուծվեն, կտեղակայվի և պահպանվի իր ողջ կյանքի ցիկլի ընթացքում: ClickHouse կլաստերը Kubernetes-ում:

Եվ մենք փորձեցինք լուծում տալ, որը կօգնի հեշտացնել աշխատանքը։ Սա ClickHouse-օպերատոր է Kubernetes-ի համար Altinity-ից:

Օպերատորը ծրագիր է, որի հիմնական խնդիրն է կառավարել այլ ծրագրեր, այսինքն՝ կառավարիչ է։

Եվ այն պարունակում է վարքի օրինաչափություններ: Դուք կարող եք անվանել սա կոդավորված գիտելիքներ առարկայի վերաբերյալ:

Եվ նրա հիմնական խնդիրն է հեշտացնել DevOps-ի կյանքը և նվազեցնել միկրոկառավարումը, որպեսզի նա (DevOps) արդեն մտածի բարձր մակարդակով, այսինքն, որպեսզի ինքը (DevOps) չզբաղվի միկրոկառավարմամբ, որպեսզի չկարգավորի: բոլոր մանրամասները ձեռքով:

Եվ պարզապես օպերատորը ռոբոտային օգնական է, ով զբաղվում է միկրոխնդիրներով և օգնում է DevOps-ին:

Ինչու՞ է ձեզ անհրաժեշտ օպերատոր: Նա հատկապես լավ է հանդես գալիս երկու ոլորտներում.

• Երբ ClickHouse-ով զբաղվող մասնագետը չունի բավարար փորձ, բայց արդեն պետք է աշխատի ClickHouse-ը, օպերատորը հեշտացնում է գործողությունը և թույլ է տալիս գործարկել ClickHouse կլաստերը բավականին բարդ կազմաձևով, առանց շատ մանրամասնելու, թե ինչպես է այն աշխատում: ներսում։ Դուք պարզապես նրան տալիս եք բարձր մակարդակի առաջադրանքներ, և դա ստացվում է:
• Եվ երկրորդ խնդիրը, որում այն ​​լավագույնս է կատարում, երբ անհրաժեշտ է ավտոմատացնել մեծ թվով բնորոշ առաջադրանքներ: Հեռացնում է microtasks-ը համակարգի ադմինիստրատորներից:

Սա առավել անհրաժեշտ է կամ նրանց, ովքեր նոր են սկսում իրենց ճանապարհորդությունը, կամ նրանց, ովքեր պետք է շատ ավտոմատացում անեն:

Ինչպե՞ս է օպերատորի վրա հիմնված մոտեցումը տարբերվում այլ համակարգերից: Կա Հելմ. Այն նաև օգնում է տեղադրել ClickHouse-ը, դուք կարող եք նկարել ղեկային գծապատկերներ, որոնք նույնիսկ կտեղադրեն ClickHouse-ի մի ամբողջ կլաստեր: Այդ դեպքում ո՞րն է տարբերությունը օպերատորի և նույնի, օրինակ, Հելմի միջև:

Հիմնական հիմնարար տարբերությունն այն է, որ Helm-ը փաթեթի կառավարումն է, իսկ օպերատորը մի քայլ առաջ է գնում: Սա աջակցություն է ողջ կյանքի ցիկլի համար: Սա միայն տեղադրում չէ, դրանք ամենօրյա առաջադրանքներ են, որոնք ներառում են մասշտաբավորում, բեկում, այսինքն՝ այն ամենը, ինչ պետք է արվի կյանքի ցիկլի ընթացքում (անհրաժեշտության դեպքում՝ նաև ջնջում), այս ամենը որոշում է օպերատորը: Այն փորձում է ավտոմատացնել և պահպանել ծրագրաշարի ողջ կյանքի ցիկլը: Սա է դրա հիմնարար տարբերությունը ներկայացված այլ լուծումներից:

Դա ներածական մասն էր, անցնենք առաջ։

Ինչպե՞ս ենք մենք կառուցում մեր օպերատորը: Մենք փորձում ենք մոտենալ խնդրին՝ ClickHouse կլաստերը որպես մեկ ռեսուրս կառավարելու համար:

Այստեղ մենք մուտքագրված տվյալներ ունենք նկարի ձախ կողմում: Սա YAML-ն է՝ կլաստերի ճշգրտմամբ, որը դասական եղանակով փոխանցվում է Kubernetes-ին kubectl-ի միջոցով։ Այնտեղ մեր օպերատորը վերցնում է այն և անում իր կախարդանքը: Եվ ելքում մենք ստանում ենք հետևյալ սխեման. Սա ClickHouse-ի իրականացումն է Kubernetes-ում:

Եվ հետո մենք կամաց-կամաց կնայենք, թե կոնկրետ ինչպես է աշխատում օպերատորը, ինչ բնորոշ խնդիրներ կարելի է լուծել։ Մենք կքննարկենք միայն տիպիկ առաջադրանքները, քանի որ ժամանակի սահմանափակ հնարավորություն ունենք: Եվ այն ամենը, ինչ օպերատորը կարող է որոշել, չի քննարկվելու։

Սկսենք պրակտիկայից. Մեր նախագիծը լիովին բաց կոդով է, այնպես որ կարող եք տեսնել, թե ինչպես է այն աշխատում GitHub-ում: Եվ դուք կարող եք ելնել այն նկատառումներից, որ եթե դուք պարզապես ցանկանում եք այն գործարկել, ապա կարող եք սկսել «Արագ մեկնարկի ուղեցույցից»:

Եթե ​​ցանկանում եք մանրամասնորեն հասկանալ, ապա մենք փորձում ենք պահպանել փաստաթղթերը քիչ թե շատ պատշաճ ձևով:

Սկսենք գործնական խնդրից. Առաջին խնդիրը, որտեղ մենք բոլորս ուզում ենք սկսել, առաջին օրինակը ինչ-որ կերպ գործարկելն է: Ինչպե՞ս կարող եմ գործարկել ClickHouse-ը օպերատորի միջոցով, նույնիսկ եթե ես իսկապես չգիտեմ, թե ինչպես է այն աշխատում: Մենք մանիֆեստ ենք գրում, քանի որ... K8s-ի հետ ամբողջ շփումը մանիֆեստների միջոցով է:

Սա այնքան բարդ մանիֆեստ է։ Այն, ինչ մենք ընդգծել ենք կարմիրով, այն է, ինչի վրա պետք է կենտրոնանանք: Մենք խնդրում ենք օպերատորին ստեղծել դեմո անունով կլաստեր:

Սրանք առայժմ հիմնական օրինակներ են: Պահպանումը դեռ նկարագրված չէ, բայց մենք կվերադառնանք պահեստին մի փոքր ուշ: Առայժմ մենք կդիտարկենք կլաստերի զարգացման դինամիկան:

Մենք ստեղծել ենք այս մանիֆեստը։ Մենք այն կերակրում ենք մեր օպերատորին: Աշխատում էր, մոգություն էր անում։

Մենք նայում ենք վահանակին: Հետաքրքրություն է ներկայացնում երեք բաղադրիչ՝ Pod, երկու Ծառայություններ և StatefulSet:

Օպերատորն աշխատել է, և մենք կարող ենք տեսնել, թե կոնկրետ ինչ է նա ստեղծել։

Նա նման բան է ստեղծում. Մենք ունենք StatefulSet, Pod, ConfigMap յուրաքանչյուր կրկնօրինակի համար, ConfigMap ամբողջ կլաստերի համար: Ծառայությունները պահանջվում են որպես կլաստերի մուտքի կետեր:

Ծառայությունները կենտրոնական Load Balancer Service-ն են և կարող են օգտագործվել նաև յուրաքանչյուր կրկնօրինակի, յուրաքանչյուր բեկորի համար:

Մեր հիմնական կլաստերը այսպիսի տեսք ունի. Այն մեկ հանգույցից է:

Եկեք ավելի առաջ գնանք և բարդացնենք ամեն ինչ: Մենք պետք է մասնատենք կլաստերը:

Մեր առաջադրանքները մեծանում են, դինամիկան սկսվում է։ Մենք ուզում ենք բեկոր ավելացնել: Մենք հետևում ենք զարգացմանը. Մենք փոխում ենք մեր բնութագրերը: Մենք նշում ենք, որ մենք ուզում ենք երկու բեկոր:

Սա նույն ֆայլն է, որը դինամիկ կերպով զարգանում է համակարգի աճով: Պահպանման ոչ, պահեստավորումը կքննարկվի հետագա, սա առանձին թեմա է։

Մենք կերակրում ենք YAML օպերատորին և տեսնում ենք, թե ինչ է տեղի ունենում:

Օպերատորը մտածեց և կազմեց հետևյալ սուբյեկտները. Մենք արդեն ունենք երկու Pods, երեք ծառայություն և, հանկարծ, 2 StatefulSets: Ինչու՞ 2 StatefulSets:

Դիագրամի վրա այսպես էր. սա մեր նախնական վիճակն է, երբ ունեինք մեկ պատիճ:

Դարձավ այսպես. Մինչ այժմ ամեն ինչ պարզ է, այն կրկնօրինակվել է։

Իսկ ինչու՞ այնտեղ դարձան երկու StatefulSets: Այստեղ մենք պետք է շեղվենք և քննարկենք այն հարցը, թե ինչպես են Pods-ը կառավարվում Kubernetes-ում:

Կա StatefulSet կոչվող օբյեկտ, որը թույլ է տալիս ձևանմուշից ստեղծել Pods-ի հավաքածու: Այստեղ հիմնական գործոնը Կաղապարն է: Եվ դուք կարող եք գործարկել բազմաթիվ Pods՝ օգտագործելով մեկ ձևանմուշ մեկ StatefulSet-ում: Եվ այստեղ հիմնական արտահայտությունն է «շատ պատյաններ մեկ ձևանմուշի համար»:

Եվ մեծ գայթակղություն կար ամբողջ կլաստերը ստեղծելու՝ փաթեթավորելով այն մեկ StatefulSet-ի մեջ: Կաշխատի, խնդիր չկա: Բայց կա մեկ նախազգուշացում. Եթե ​​մենք ուզում ենք հավաքել տարասեռ կլաստեր, այսինքն՝ ClickHouse-ի մի քանի տարբերակներից, ապա սկսում են հարցեր առաջանալ։ Այո, StatefulSet-ը կարող է կատարել պտտվող թարմացում, և այնտեղ դուք կարող եք թողարկել նոր տարբերակ, բացատրել, որ դուք պետք է փորձեք ոչ ավելի, քան այդքան հանգույցներ միաժամանակ:

Բայց եթե մենք էքստրապոլյացիա անենք առաջադրանքը և ասենք, որ մենք ցանկանում ենք ստեղծել միանգամայն տարասեռ կլաստեր, և չենք ցանկանում փոխել հին տարբերակից նորը` օգտագործելով շարժական թարմացում, այլ պարզապես ցանկանում ենք ստեղծել տարասեռ կլաստեր երկու առումով: ClickHouse-ի տարբեր տարբերակների և տարբեր պահեստավորման առումով: Մենք ուզում ենք, օրինակ, մի քանի կրկնօրինակներ պատրաստել առանձին սկավառակների վրա, դանդաղների վրա, ընդհանրապես, ամբողջությամբ կառուցել տարասեռ կլաստեր։ Եվ քանի որ StatefulSet-ը ստանդարտացված լուծում է պատրաստում մեկ ձևանմուշից, դա անելու միջոց չկա։

Որոշ մտածելուց հետո որոշվեց, որ մենք դա անելու ենք այսպես. Մենք ունենք յուրաքանչյուր կրկնօրինակ իր StatefulSet-ում: Այս լուծումը որոշ թերություններ ունի, բայց գործնականում այն ​​ամբողջությամբ ծածկված է օպերատորի կողմից: Եվ կան շատ առավելություններ. Մենք կարող ենք կառուցել մեր ուզած ճշգրիտ կլաստերը, օրինակ՝ բացարձակապես տարասեռ: Հետևաբար, մի կլաստերում, որտեղ մենք ունենք երկու բեկորներ մեկ կրկնօրինակով, մենք կունենանք 2 StatefulSets և 2 Pods հենց այն պատճառով, որ մենք ընտրել ենք այս մոտեցումը վերը նշված պատճառներով, որպեսզի կարողանանք ստեղծել տարասեռ կլաստեր:

Վերադառնանք գործնական խնդիրներին։ Մեր կլաստերում մենք պետք է կարգավորենք օգտվողներին, այսինքն. դուք պետք է կատարեք ClickHouse-ի որոշակի կոնֆիգուրացիա Kubernetes-ում: Օպերատորը դրա համար տալիս է բոլոր հնարավորությունները։

Մենք կարող ենք գրել այն, ինչ ուզում ենք ուղղակիորեն YAML-ում: Կազմաձևման բոլոր տարբերակները քարտեզագրվում են անմիջապես այս YAML-ից ClickHouse-ի կոնֆիգուրացիաների մեջ, որոնք այնուհետև բաշխվում են ամբողջ կլաստերում:

Կարող եք գրել այսպես. Սա օրինակ. Գաղտնաբառը կարող է կոդավորված լինել: Բացարձակապես բոլոր ClickHouse-ի կազմաձևման տարբերակներն ապահովված են: Ահա ընդամենը մի օրինակ.

Կլաստերի կոնֆիգուրացիան բաշխված է որպես ConfigMap: Գործնականում ConfigMap-ի թարմացումն ակնթարթորեն չի առաջանում, հետևաբար, եթե կլաստերը մեծ է, ապա կազմաձևումը մղելու գործընթացը որոշ ժամանակ է պահանջում: Բայց այս ամենը շատ հարմար է օգտագործելու համար։

Եկեք բարդացնենք խնդիրը. Կլաստերը զարգանում է։ Մենք ցանկանում ենք կրկնօրինակել տվյալները: Այսինքն, մենք արդեն ունենք երկու բեկոր, յուրաքանչյուրը մեկ կրկնօրինակ, և օգտվողները կազմաձևված են: Մենք աճում ենք և ցանկանում ենք կրկնօրինակել:

Ի՞նչ է մեզ անհրաժեշտ կրկնօրինակման համար:

Մեզ ZooKeeper է պետք։ ClickHouse-ում կրկնօրինակումը կառուցվում է ZooKeeper-ի միջոցով: ZooKeeper-ն անհրաժեշտ է, որպեսզի ClickHouse-ի տարբեր կրկնօրինակները կոնսենսուս ունենան, թե որ տվյալների բլոկներն են գտնվում ClickHouse-ի վրա:

ZooKeeper-ը կարող է օգտագործվել բոլորի կողմից: Եթե ​​ձեռնարկությունն ունի արտաքին ZooKeeper, ապա այն կարող է օգտագործվել: Եթե ​​ոչ, կարող եք տեղադրել այն մեր պահոցից: Կա տեղադրող, որը հեշտացնում է այս ամբողջ գործը:

Եվ ամբողջ համակարգի փոխազդեցության դիագրամը ստացվում է այսպես. Մենք ունենք Kubernetes որպես հարթակ: Այն իրականացնում է ClickHouse օպերատորը: Այստեղ ես պատկերեցի ZooKeeper-ը: Իսկ օպերատորը համագործակցում է ինչպես ClickHouse-ի, այնպես էլ ZooKeeper-ի հետ: Այսինքն՝ փոխազդեցության արդյունքներ։

Եվ այս ամենը անհրաժեշտ է, որպեսզի ClickHouse-ը հաջողությամբ կրկնօրինակի տվյալները k8s-ում:

Հիմա նայենք բուն առաջադրանքին, թե ինչպիսին կլինի կրկնօրինակման մանիֆեստը:

Մենք երկու բաժին ենք ավելացնում մեր մանիֆեստին: Առաջինն այն է, թե որտեղից կարելի է ձեռք բերել ZooKeeper, որը կարող է լինել կամ Kubernetes-ի ներսում, կամ արտաքին: Սա ընդամենը նկարագրություն է։ Եվ մենք պատվիրում ենք կրկնօրինակներ: Նրանք. մենք ուզում ենք երկու կրկնօրինակ: Ընդհանուր առմամբ, մենք պետք է ունենանք 4 պատիճ ելքի վրա: Մենք հիշում ենք պահեստավորման մասին, այն կվերադառնա մի փոքր ուշ: Պահպանումն առանձին պատմություն է։

Այսպես էր.

Այն դառնում է այսպես. Կրկնօրինակները ավելացվում են: 4-րդը չտեղավորվեց, կարծում ենք, որ այնտեղ կարող էին շատ լինել։ Իսկ ZooKeeper-ը ավելացվել է կողքին։ Սխեմաները դառնում են ավելի բարդ.

Եվ ժամանակն է ավելացնել հաջորդ առաջադրանքը: Մենք կավելացնենք Մշտական ​​պահեստավորում:

Մշտական ​​պահպանման համար մենք ունենք տարբեր տարբերակներ:

Եթե ​​մենք աշխատում ենք ամպային մատակարարում, օրինակ՝ օգտագործելով Amazon-ը, Google-ը, ապա մեծ գայթակղություն կա՝ օգտագործելու ամպային պահեստը: Շատ հարմար է, լավ է։

Եվ կա երկրորդ տարբերակ. Սա տեղական պահեստավորման համար է, երբ յուրաքանչյուր հանգույցի վրա ունենք տեղային սկավառակներ։ Այս տարբերակը շատ ավելի դժվար է իրականացնել, բայց միևնույն ժամանակ ավելի արդյունավետ է։

Տեսնենք, թե ինչ ունենք ամպային պահեստավորման վերաբերյալ:

Կան առավելություններ. Դա շատ հեշտ է կարգավորել: Մենք պարզապես պատվիրում ենք ամպային մատակարարից, որ խնդրում ենք մեզ տրամադրել այս կամ այն ​​հզորության, այսինչ դասի պահեստ: Դասերը պլանավորվում են մատակարարների կողմից ինքնուրույն:

Եվ կա մի թերություն. Ոմանց համար սա ոչ կրիտիկական թերություն է: Իհարկե, որոշ կատարողական խնդիրներ կլինեն: Այն շատ հարմար է օգտագործման համար և հուսալի, բայց կան որոշ պոտենցիալ կատարողական թերություններ:

Եվ քանի որ ClickHouse-ը կենտրոնանում է հատկապես արտադրողականության վրա, նույնիսկ կարելի է ասել, որ այն քամում է այն ամենը, ինչ կարող է, այդ իսկ պատճառով շատ հաճախորդներ փորձում են սեղմել առավելագույն արտադրողականությունը:

Եվ դրանից առավելագույն օգուտ քաղելու համար մեզ անհրաժեշտ է տեղական պահեստավորում:

Kubernetes-ը տրամադրում է երեք աբստրակցիա՝ Kubernetes-ում տեղական պահեստ օգտագործելու համար: Սա.

• EmptyDir
• HostPath.
• Տեղական.

Եկեք տեսնենք, թե ինչպես են դրանք տարբերվում և ինչպես են դրանք նման:

Նախ, բոլոր երեք մոտեցումներում մենք ունենք պահեստավորում. սրանք տեղական սկավառակներ են, որոնք տեղակայված են նույն ֆիզիկական k8s հանգույցում: Բայց նրանք ունեն որոշ տարբերություններ:

Սկսենք ամենապարզից, այսինքն դատարկ Դիրից: Ի՞նչ է սա գործնականում: Մեր ճշգրտման մեջ մենք խնդրում ենք կոնտեյներացման համակարգին (առավել հաճախ՝ Docker-ին) ապահովել մեզ մուտք դեպի տեղական սկավառակի թղթապանակ:

Գործնականում Docker-ը ստեղծում է ժամանակավոր թղթապանակ ինչ-որ տեղ իր սեփական ուղիների երկայնքով և այն անվանում է երկար հեշ: Եվ տրամադրում է ինտերֆեյս դրան մուտք գործելու համար:

Ինչպե՞ս է սա աշխատելու կատարողականի առումով: Սա կաշխատի տեղական սկավառակի արագությամբ, այսինքն. Սա ձեր պտուտակին լիարժեք մուտք է:

Բայց այս դեպքն ունի իր թերությունը. Համառությունն այս հարցում բավականին կասկածելի է։ Առաջին անգամ, երբ Docker-ը շարժվում է բեռնարկղերով, Persistent-ը կորչում է: Եթե ​​Kubernetes-ը ցանկանում է ինչ-ինչ պատճառներով այս Pod-ը տեղափոխել այլ սկավառակ, տվյալները կկորչեն:

Այս մոտեցումը լավ է թեստերի համար, քանի որ այն արդեն ցույց է տալիս նորմալ արագություն, բայց ինչ-որ լուրջ բանի համար այս տարբերակը հարմար չէ։

Ուստի կա երկրորդ մոտեցում. Սա hostPath-ն է: Եթե ​​նայեք նախորդ և այս սլայդին, կարող եք տեսնել միայն մեկ տարբերություն: Մեր թղթապանակը Docker-ից անմիջապես տեղափոխվեց Kubernetes հանգույց: Այստեղ մի փոքր ավելի պարզ է: Մենք ուղղակիորեն նշում ենք տեղական ֆայլային համակարգի ուղին, որտեղ մենք կցանկանայինք պահել մեր տվյալները:

Այս մեթոդն ունի առավելություններ. Սա արդեն իսկական Համառ է, ընդ որում՝ դասական: Մենք կունենանք տվյալներ գրանցված սկավառակի վրա ինչ-որ հասցեում:

Կան նաև թերություններ. Սա է կառավարման բարդությունը: Մեր Kubernetes-ը կարող է ցանկանալ տեղափոխել Pod-ը մեկ այլ ֆիզիկական հանգույց: Եվ այստեղ է, որ DevOps-ը հայտնվում է խաղի մեջ: Նա պետք է ճիշտ բացատրի ամբողջ համակարգին, որ այս բլոկները կարող են տեղափոխվել միայն այն հանգույցները, որոնց վրա դուք ինչ-որ բան տեղադրված եք այս ուղիների երկայնքով, և միաժամանակ ոչ ավելի, քան մեկ հանգույց: Դա բավականին դժվար է։

Հատկապես այս նպատակների համար մենք կաղապարներ ենք պատրաստել մեր օպերատորում, որպեսզի թաքցնենք այս ամբողջ բարդությունը։ Եվ դուք կարող եք պարզապես ասել. «Ես ուզում եմ ունենալ ClickHouse-ի մեկ օրինակ յուրաքանչյուր ֆիզիկական հանգույցի համար և այս կամ այն ​​ճանապարհի երկայնքով»:

Բայց մենք միակը չենք, ում կարիքն ունի այս կարիքը, ուստի հենց Kubernetes-ի պարոնայք նույնպես հասկանում են, որ մարդիկ ցանկանում են մուտք ունենալ դեպի ֆիզիկական սկավառակներ, ուստի նրանք ապահովում են երրորդ շերտ:

Այն կոչվում է տեղական: Գործնականում տարբերություն չկա նախորդ սլայդից: Միայն նախքան անհրաժեշտ էր ձեռքով հաստատել, որ մենք չենք կարող փոխանցել այս պատյանները հանգույցից հանգույց, քանի որ դրանք պետք է կցվեն ինչ-որ ճանապարհով դեպի տեղական ֆիզիկական սկավառակ, բայց այժմ այս ամբողջ գիտելիքը պարփակված է հենց Kubernetes-ում: Եվ պարզվում է, որ շատ ավելի հեշտ է կարգավորել:

Վերադառնանք մեր գործնական խնդրին։ Վերադառնանք YAML կաղապարին։ Այստեղ մենք ունենք իրական պահեստ: Մենք վերադարձել ենք դրան: Մենք դրեցինք դասական VolumeClaim ձևանմուշը, ինչպես k8s-ում: Եվ մենք նկարագրում ենք, թե ինչպիսի պահեստ ենք ուզում:

Դրանից հետո k8s-ը կպահանջի պահեստավորում: Այն մեզ կտրամադրի StatefulSet-ում: Եվ վերջում այն ​​կլինի ClickHouse-ի տրամադրության տակ։

Մենք ունեինք այս սխեման. Մեր մշտական ​​պահեստը կարմիր էր, ինչը կարծես հուշում էր, որ դա պետք է անել:

Եվ այն դառնում է կանաչ: Այժմ ClickHouse on k8s կլաստերի սխեման ամբողջությամբ վերջնական տեսքի է բերվել: Մենք ունենք բեկորներ, կրկնօրինակներ, ZooKeeper, ունենք իրական Persistent, որն այս կամ այն ​​կերպ իրականացվում է։ Սխեման արդեն ամբողջությամբ գործում է։

Մենք շարունակում ենք ապրել։ Մեր կլաստերը զարգանում է։ Եվ Ալեքսեյը փորձում է և թողարկում ClickHouse-ի նոր տարբերակը:

Գործնական խնդիր է առաջանում՝ փորձարկել ClickHouse-ի նոր տարբերակը մեր կլաստերի վրա։ Եվ, բնականաբար, դուք չեք ցանկանում այդ ամենը շրջանառել, դուք ցանկանում եք տեղադրել նոր տարբերակը մեկ կրկնօրինակի մեջ ինչ-որ տեղ հեռավոր անկյունում, և գուցե ոչ թե մեկ նոր տարբերակ, այլ միանգամից երկու, քանի որ դրանք հաճախ են դուրս գալիս:

Ի՞նչ կարող ենք ասել այս մասին։

Այստեղ մենք ունենք հենց այդպիսի հնարավորություն։ Սրանք pod կաղապարներ են: Կարող եք գրել, որ մեր օպերատորը լիովին թույլ է տալիս կառուցել տարասեռ կլաստեր: Նրանք. կարգավորել՝ սկսած մի փունջ բոլոր կրկնօրինակներից, վերջացրած յուրաքանչյուր անձնական կրկնօրինակով, թե որ տարբերակն ենք ուզում ClickHouse, որ տարբերակով ենք պահեստավորում: Մենք կարող ենք ամբողջությամբ կարգավորել կլաստերը մեզ անհրաժեշտ կազմաձևով:

Եկեք մի փոքր խորանանք ներսը: Մինչ այս, մենք խոսեցինք այն մասին, թե ինչպես է աշխատում ClickHouse-օպերատորը` կապված ClickHouse-ի առանձնահատկությունների հետ:

Այժմ ես կցանկանայի մի քանի խոսք ասել, թե ինչպես է աշխատում ցանկացած օպերատոր ընդհանրապես, ինչպես նաև ինչպես է այն փոխազդում K8-ների հետ։

Եկեք նախ նայենք K8-ների հետ փոխգործակցությանը: Ի՞նչ է տեղի ունենում, երբ մենք դիմում ենք kubectl-ին: Մեր օբյեկտները հայտնվում են etcd-ում API-ի միջոցով:

Օրինակ՝ հիմնական Kubernetes-ի օբյեկտները՝ pod, StatefulSet, service և այլն ցանկում:

Ընդ որում, ֆիզիկական ոչինչ դեռ չի լինում։ Այս օբյեկտները պետք է նյութականացվեն կլաստերի մեջ:

Այդ նպատակով հայտնվում է վերահսկիչ: Կարգավորիչը հատուկ k8s բաղադրիչ է, որը կարող է նյութականացնել այս նկարագրությունները: Նա գիտի, թե ինչպես և ինչ անել ֆիզիկապես։ Նա գիտի, թե ինչպես վարել կոնտեյներներ, ինչ է պետք այնտեղ կարգավորել, որպեսզի սերվերը աշխատի:

Եվ դա նյութականացնում է մեր օբյեկտները K8-ներում:

Բայց մենք ցանկանում ենք գործել ոչ միայն pods-ով և StatefulSets-ով, մենք ցանկանում ենք ստեղծել ClickHouseInstallation, այսինքն՝ ClickHouse տիպի օբյեկտ, որպեսզի գործարկենք դրա հետ որպես մեկ ամբողջություն: Առայժմ նման հնարավորություն չկա։

Բայց K8s-ն ունի հետևյալ հաճելի բանը. Մենք ցանկանում ենք, որ մենք ունենանք այս բարդ կազմավորման նման մի տեղ, որտեղ մեր կլաստերը կհավաքվի pods-ից և StatefulSet-ից:

Իսկ ի՞նչ է պետք անել դրա համար։ Նախ, Պատվերով ռեսուրսների սահմանումը հայտնվում է նկարում: Ինչ է դա? Սա K8-ների նկարագրությունն է, որ դուք կունենաք ևս մեկ տվյալների տեսակ, որը մենք ցանկանում ենք ավելացնել հատուկ ռեսուրս պատիճում՝ StatefulSet, որը ներսում կլինի բարդ: Սա տվյալների կառուցվածքի նկարագրությունն է:

Մենք նաև ուղարկում ենք այնտեղ kubectl application-ի միջոցով։ Կուբերնետեսը ուրախությամբ վերցրեց այն:

Եվ հիմա մեր պահեստում, etcd-ում գտնվող օբյեկտը հնարավորություն ունի գրանցելու մաքսային ռեսուրս, որը կոչվում է ClickHouseInstallation:

Բայց առայժմ ոչինչ այլևս չի լինի։ Այսինքն, եթե մենք հիմա ստեղծենք YAML ֆայլը, որը մենք նայեցինք՝ նկարագրելով բեկորները և կրկնօրինակները և ասենք «kubectl application», ապա Kubernetes-ը կընդունի այն, կդնի և այլն և կասի. «Հիանալի է, բայց ես չգիտեմ, թե ինչ անել: դրանով. Ես չգիտեմ, թե ինչպես պահպանել ClickHouseInstallation-ը»:

Համապատասխանաբար, մեզ պետք է ինչ-որ մեկը, ով կօգնի Kubernetes-ին սպասարկել տվյալների նոր տեսակը: Ձախ կողմում մենք ունենք հայրենական Kubernetes կարգավորիչ, որն աշխատում է տվյալների բնօրինակ տեսակների հետ: Իսկ աջ կողմում մենք պետք է ունենանք հատուկ վերահսկիչ, որը կարող է աշխատել հատուկ տվյալների տեսակների հետ:

Եվ այլ կերպ այն կոչվում է օպերատոր։ Ես այն հատուկ ներառել եմ այստեղ որպես Kubernetes, քանի որ այն կարող է իրականացվել նաև K8-ներից դուրս: Ամենից հաճախ, իհարկե, բոլոր օպերատորները մահապատժի են ենթարկվում Kubernetes-ում, բայց ոչինչ չի խանգարում նրան դրսում կանգնել, ուստի այստեղ այն հատուկ տեղափոխվում է դրսում։

Եվ իր հերթին, մաքսային վերահսկիչը, որը նաև հայտնի է որպես օպերատոր, համագործակցում է Kubernetes-ի հետ API-ի միջոցով: Այն արդեն գիտի, թե ինչպես համագործակցել API-ի հետ: Եվ նա արդեն գիտի, թե ինչպես նյութականացնել այն բարդ միացումը, որը մենք ցանկանում ենք ստեղծել հատուկ ռեսուրսից: Սա հենց այն է, ինչ անում է օպերատորը:

Ինչպե՞ս է աշխատում օպերատորը: Եկեք նայենք աջ կողմին, որպեսզի տեսնենք, թե ինչպես է դա անում: Եկեք պարզենք, թե ինչպես է օպերատորը նյութականացնում այս ամենը և ինչպես է տեղի ունենում հետագա փոխգործակցությունը K8-ների հետ:

Օպերատորը ծրագիր է։ Նա միտված է իրադարձություններին: Օպերատորը բաժանորդագրվում է իրադարձությունների՝ օգտագործելով Kubernetes API: Kubernetes API-ն ունի մուտքի կետեր, որտեղ դուք կարող եք բաժանորդագրվել իրադարձություններին: Իսկ եթե K8-ներում ինչ-որ բան փոխվում է, ապա Kubernetes-ը իրադարձություններ է ուղարկում բոլորին, այսինքն. ով բաժանորդագրվել է այս API կետին, կստանա ծանուցումներ:

Օպերատորը բաժանորդագրվում է իրադարձություններին և պետք է ինչ-որ կերպ արձագանքի: Նրա խնդիրն է արձագանքել ի հայտ եկած իրադարձություններին:

Իրադարձությունները ստեղծվում են որոշակի թարմացումներով: Մեր YAML ֆայլը՝ ClickHouseInstallation-ի նկարագրությամբ: Նա գնաց etcd-ի kubectl application-ի միջոցով: Այնտեղ տեղի ունեցավ իրադարձություն, և արդյունքում այս իրադարձությունը հասավ ClickHouse-օպերատորին: Օպերատորը ստացել է այս նկարագրությունը. Եվ նա պետք է ինչ-որ բան անի: Եթե ​​թարմացում է եկել ClickHouseInstallation օբյեկտի համար, ապա դուք պետք է թարմացնեք կլաստերը: Իսկ օպերատորի խնդիրն է թարմացնել կլաստերը:

Ինչ է նա անում? Նախ, մենք պետք է գործողությունների ծրագիր կազմենք, թե ինչ ենք անելու այս թարմացման հետ: Թարմացումները կարող են լինել շատ փոքր, այսինքն. փոքր է YAML-ի կատարման մեջ, բայց կարող է հանգեցնել շատ մեծ փոփոխություններ կլաստերի վրա: Հետևաբար, օպերատորը ստեղծում է պլան, այնուհետև մնում է դրան:

Ըստ այս ծրագրի, նա սկսում է եփել այս կառույցը ներսում, որպեսզի նյութականացնի պատիճները, ծառայությունները, այսինքն. անել այն, ինչ նրա հիմնական խնդիրն է: Ահա թե ինչպես կարելի է ստեղծել ClickHouse կլաստեր Kubernetes-ում:

Հիմա անդրադառնանք այսպիսի հետաքրքիր բանի. Սա պատասխանատվության բաժանում է Kubernetes-ի և օպերատորի միջև, այսինքն. ինչ է անում Kubernetes-ը, ինչ է անում օպերատորը և ինչպես են նրանք փոխազդում միմյանց հետ:

Kubernetes-ը պատասխանատու է համակարգային բաների համար, այսինքն. օբյեկտների հիմնական հավաքածուի համար, որոնք կարող են մեկնաբանվել որպես համակարգ-շրջանակ: Kubernetes-ը գիտի, թե ինչպես գործարկել pods, ինչպես վերագործարկել կոնտեյներները, ինչպես տեղադրել ծավալներ, ինչպես աշխատել ConfigMap-ի հետ, այսինքն. այն ամենը, ինչ կարելի է համակարգ անվանել։

Օպերատորները գործում են տիրույթներում: Յուրաքանչյուր օպերատոր ստեղծված է իր առարկայական տարածքի համար: Մենք դա արել ենք ClickHouse-ի համար:

Իսկ օպերատորը փոխազդում է հենց թեմայի տարածքի առումով, օրինակ՝ կրկնօրինակի ավելացում, դիագրամ կազմելու, մոնիտորինգի կարգավորում: Սա հանգեցնում է բաժանման:

Եկեք նայենք գործնական օրինակին, թե ինչպես է առաջանում պատասխանատվության այս բաժանումը, երբ մենք կատարում ենք ավելացնել կրկնօրինակի գործողությունը:

Օպերատորը ստանում է առաջադրանք՝ ավելացնել կրկնօրինակը: Ի՞նչ է անում օպերատորը: Օպերատորը հաշվարկելու է, որ պետք է ստեղծվի նոր StatefulSet, որտեղ պետք է նկարագրվեն այս կամ այն ​​ձևանմուշները, ծավալի պահանջը:

Նա պատրաստել է այդ ամենը և փոխանցում է K8-ներին։ Նա ասում է, որ իրեն պետք է ConfigMap, StatefulSet, Volume։ Kubernetes-ը աշխատում է։ Նա նյութականացնում է հիմնական ստորաբաժանումները, որոնց հետ նա գործում է:

Եվ հետո ClickHouse-օպերատորը նորից գործի է անցնում: Նա արդեն ունի ֆիզիկական պատիճ, որի վրա արդեն կարող է ինչ-որ բան անել: Եվ ClickHouse-operator-ը կրկին աշխատում է տիրույթի առումով: Նրանք. Հատկապես ClickHouse-ը, որպեսզի կրկնօրինակը ներառվի կլաստերի մեջ, նախ պետք է կարգավորեք տվյալների սխեման, որը գոյություն ունի այս կլաստերում: Եվ, երկրորդ, այս կրկնօրինակը պետք է ներառվի մոնիտորինգի մեջ, որպեսզի հստակ հայտնաբերվի: Օպերատորն արդեն կարգավորել է սա:

Եվ միայն դրանից հետո է գործի դնում ինքը՝ ClickHouse-ը, այսինքն. մեկ այլ ավելի բարձր մակարդակի սուբյեկտ: Սա արդեն տվյալների բազա է։ Այն ունի իր սեփական օրինակը, մեկ այլ կազմաձևված կրկնօրինակ, որը պատրաստ է միանալու կլաստերին:

Ստացվում է, որ կրկնօրինակն ավելացնելիս կատարման և պատասխանատվության բաժանման շղթան բավականին երկար է։

Մենք շարունակում ենք մեր գործնական առաջադրանքները։ Եթե ​​դուք արդեն ունեք կլաստեր, կարող եք տեղափոխել կազմաձևը:

Մենք դա արել ենք այնպես, որ դուք կարող եք անմիջապես տեղադրել գոյություն ունեցող xml-ի մեջ, որը ClickHouse-ը հասկանում է:

Դուք կարող եք ճշգրտորեն կարգավորել ClickHouse-ը: Պարզապես գոտիավորված տեղակայումն այն է, ինչի մասին ես խոսեցի hostPath-ը, տեղական պահեստը բացատրելիս: Ահա թե ինչպես ճիշտ կատարել գոտիավորված տեղակայումը:

Հաջորդ գործնական խնդիրը մոնիտորինգն է։

Եթե ​​մեր կլաստերը փոխվում է, ապա մենք պետք է պարբերաբար կարգավորենք մոնիտորինգը:

Եկեք նայենք դիագրամին: Այստեղ արդեն նայեցինք կանաչ սլաքներին։ Հիմա եկեք նայենք կարմիր սլաքներին: Ահա թե ինչպես ենք մենք ցանկանում վերահսկել մեր կլաստերը: Ինչպե՞ս են ClickHouse կլաստերի չափումները մտնում Պրոմեթևս, այնուհետև Գրաֆանա:

Ո՞րն է մոնիտորինգի դժվարությունը: Ինչո՞ւ է սա ներկայացվում որպես ինչ-որ ձեռքբերում։ Դժվարությունը դինամիկայի մեջ է։ Երբ մենք ունենք մեկ կլաստեր, և այն ստատիկ է, ապա մենք կարող ենք մեկ անգամ տեղադրել մոնիտորինգ և այլևս չանհանգստանալ:

Բայց եթե մենք ունենք շատ կլաստերներ, կամ ինչ-որ բան անընդհատ փոխվում է, ապա գործընթացը դինամիկ է: Եվ մոնիտորինգի անընդհատ վերակազմավորումը ռեսուրսների և ժամանակի վատնում է, այսինքն. նույնիսկ պարզապես ծուլություն: Սա պետք է ավտոմատացված լինի: Դժվարությունը գործընթացի դինամիկայի մեջ է։ Եվ օպերատորը դա շատ լավ ավտոմատացնում է:

Ինչպե՞ս զարգացավ մեր կլաստերը: Սկզբում նա այդպիսին էր։

Հետո նա այսպիսին էր.

Ի վերջո նա դարձավ այսպիսին.

Իսկ մոնիտորինգը կատարվում է ավտոմատ կերպով օպերատորի կողմից։ Մուտքի մեկ կետ.

Եվ հենց ելքի մոտ մենք նայում ենք Grafana-ի վահանակին՝ տեսնելու, թե ինչպես է մեր կլաստերի կյանքը ներսում եռում:

Ի դեպ, Grafana-ի վահանակը նույնպես բաշխվում է մեր օպերատորի հետ անմիջապես սկզբնաղբյուրում։ Դուք կարող եք միացնել և օգտագործել: Մեր DevOps-ն ինձ տվեց այս սքրինշոթը:

Որտե՞ղ կցանկանայինք գնալ հաջորդիվ: Սա.

• Մշակել թեստային ավտոմատացում: Հիմնական խնդիրը նոր տարբերակների ավտոմատացված փորձարկումն է։
• Մենք նաև իսկապես ցանկանում ենք ավտոմատացնել ZooKeeper-ի հետ ինտեգրումը: Իսկ ZooKeeper-օպերատորի հետ ինտեգրվելու ծրագրեր կան: Նրանք. ZooKeeper-ի համար օպերատոր է գրվել, և տրամաբանական է, որ երկու օպերատորները սկսում են ինտեգրվել՝ ավելի հարմար լուծում ստեղծելու համար։
• Մենք ուզում ենք ավելի բարդ կենսական նշաններ անել։
• Ես կանաչով ընդգծեցի, որ մենք մոտենում ենք Կաղապարների ժառանգությանը - ԿԱՏԱՐՎԱԾ, այսինքն՝ օպերատորի հաջորդ թողարկումով մենք արդեն կունենանք կաղապարների ժառանգություն: Սա հզոր գործիք է, որը թույլ է տալիս կտորներից բարդ կոնֆիգուրացիաներ կառուցել:
• Եվ մենք ցանկանում ենք բարդ առաջադրանքների ավտոմատացում։ Հիմնականը Re-sharding-ն է։

Վերցնենք որոշ միջանկյալ արդյունքներ:

Ի՞նչ ենք մենք ստանում արդյունքում։ Իսկ արժե՞ անել, թե՞ ոչ։ Արդյո՞ք անհրաժեշտ է նույնիսկ փորձել տվյալների բազան քաշել Kubernetes-ի մեջ և օգտագործել օպերատորը ընդհանրապես և Alitnity օպերատորը մասնավորապես:

Ելքում մենք ստանում ենք.

• Կազմաձևման, տեղակայման և սպասարկման զգալի պարզեցում և ավտոմատացում:
• Անմիջապես ներկառուցված մոնիտորինգ:
• Եվ պատրաստի կոդավորված կաղապարներ բարդ իրավիճակների համար: Նման գործողությունը, ինչպիսին է կրկնօրինակի ավելացումը, պետք չէ ձեռքով անել: Օպերատորը դա անում է:

Մնաց միայն մի վերջին հարց. Մենք արդեն ունենք տվյալների բազա Kubernetes-ում, վիրտուալացում: Ինչ վերաբերում է նման լուծման կատարմանը, հատկապես, որ ClickHouse-ը օպտիմիզացված է կատարողականի համար:

Պատասխանն այն է, որ ամեն ինչ լավ է: Չեմ մանրամասնի, սա առանձին զեկույցի թեմա է։

Բայց կա TSBS-ի նման նախագիծ: Ո՞րն է նրա հիմնական խնդիրը: Սա տվյալների բազայի կատարողականի թեստ է: Սա փորձ է համեմատել տաքը տաքի հետ, փափուկը փափուկի հետ։

Ինչպե՞ս է նա աշխատում: Ստեղծվում է մեկ տվյալների հավաքածու: Այնուհետև տվյալների այս հավաքածուն գործարկվում է տարբեր տվյալների բազաների վրա՝ օգտագործելով թեստերի նույն փաթեթը: Եվ յուրաքանչյուր շտեմարան լուծում է մեկ խնդիր իր իմացած ձևով: Եվ հետո դուք կարող եք համեմատել արդյունքները:

Այն արդեն աջակցում է տվյալների բազաների մեծ փունջ: Ես առանձնացրել եմ երեք հիմնական. Սա.

• TimescaleDB.
• InfluxDB.
• ClickHouse.

Համեմատություն է արվել նաև մեկ այլ նմանատիպ լուծման հետ։ Համեմատություն RedShift-ի հետ։ Համեմատությունը կատարվել է Amazon-ում։ ClickHouse-ը նույնպես այս հարցում բոլորից շատ առաջ է:

Ի՞նչ եզրակացություններ կարելի է անել իմ ասածից։

• DB-ն Kubernetes-ում հնարավոր է: Հավանաբար ցանկացածը հնարավոր է, բայց ընդհանուր առմամբ, թվում է, թե դա հնարավոր է: ClickHouse-ը Kubernetes-ում միանշանակ հնարավոր է մեր օպերատորի օգնությամբ։
• Օպերատորն օգնում է ավտոմատացնել գործընթացները և իսկապես հեշտացնում է կյանքը:
• Կատարումը նորմալ է:
• Եվ մեզ թվում է, որ սա կարելի է և պետք է օգտագործել։

Բաց կոդով - միացե՛ք մեզ:

Ինչպես արդեն ասացի, օպերատորը լիովին բաց կոդով արտադրանք է, ուստի շատ լավ կլիներ, որ առավելագույն թվով մարդիկ օգտագործեին այն։ Միացեք մեզ! Սպասում ենք բոլորիդ!

Շնորհակալություն բոլորին!

Հարցեր

Շնորհակալություն զեկույցի համար: Իմ անունը Անտոն է։ Ես SEMrush-ից եմ: Ինձ հետաքրքրում է, թե ինչ կապ ունի անտառահատումները: Մենք լսում ենք մոնիտորինգի մասին, բայց ոչ մի անտառահատումների մասին, եթե խոսենք ամբողջ կլաստերի մասին: Օրինակ, մենք ստեղծել ենք կլաստեր ապարատային սարքավորումների վրա: Եվ մենք օգտագործում ենք կենտրոնացված անտառահատումներ՝ դրանք հավաքելով սովորական կույտի մեջ՝ օգտագործելով ստանդարտ միջոցներ: Եվ հետո այնտեղից մենք ստանում ենք մեզ հետաքրքրող տվյալները։

Լավ հարց է, այսինքն՝ մուտք գործել անելիքների ցուցակ: Մեր օպերատորը դա դեռ չի ավտոմատացնում: Այն դեռ զարգանում է, նախագիծը դեռ բավականին երիտասարդ է։ Մենք հասկանում ենք անտառահատումների անհրաժեշտությունը: Սա նույնպես շատ կարևոր թեմա է։ Եվ դա, հավանաբար, ոչ պակաս կարևոր է, քան մոնիտորինգը։ Բայց իրականացման ցուցակում առաջինը մոնիտորինգն էր: Կլինեն անտառահատումներ. Բնականաբար, մենք փորձում ենք ավտոմատացնել կլաստերի կյանքի բոլոր ասպեկտները: Հետևաբար, պատասխանն այն է, որ այս պահին օպերատորը, ցավոք, չգիտի, թե ինչպես դա անել, բայց դա պլանների մեջ է, մենք դա կանենք։ Եթե ​​ցանկանում եք միանալ, ապա դիմեք հարցումը, խնդրում եմ:

Բարեւ Ձեզ! Շնորհակալություն զեկույցի համար: Ես ստանդարտ հարց ունեմ՝ կապված մշտական ​​ծավալների հետ: Երբ մենք ստեղծում ենք կոնֆիգուրացիա այս օպերատորի հետ, ինչպե՞ս է օպերատորը որոշում, թե որ հանգույցի վրա ենք կցված որոշակի սկավառակ կամ թղթապանակ: Մենք նախ պետք է բացատրենք նրան, որ խնդրում ենք տեղադրել մեր ClickHouse-ը այս հանգույցների վրա, որոնք ունեն սկավառակ:

Որքան հասկանում եմ, այս հարցը լոկալ պահեստի շարունակությունն է, հատկապես դրա hostPath հատվածը։ Սա նման է ամբողջ համակարգին բացատրելու, որ pod-ը պետք է գործարկվի այսինչ հանգույցի վրա, որին մենք ունենք ֆիզիկապես միացված սկավառակ, որը տեղադրված է այսինչ ճանապարհով: Սա մի ամբողջ հատված է, որին ես շոշափեցի շատ մակերեսորեն, քանի որ այնտեղ պատասխանը բավականին մեծ է։

Համառոտ կարծես այսպես. Բնականաբար, մենք պետք է տրամադրենք այդ ծավալները։ Այս պահին տեղական պահեստում դինամիկ դրույթ չկա, ուստի DevOps-ը պետք է ինքնուրույն կտրի սկավառակները՝ այս ծավալները։ Եվ նրանք պետք է բացատրեն Kubernetes-ի տրամադրումը, որ դուք կունենաք այս և այն դասի մշտական ​​հատորներ, որոնք տեղակայված են այս կամ այն ​​հանգույցների վրա: Այնուհետև դուք պետք է բացատրեք Kubernetes-ին, որ պատիճները, որոնք պահանջում են տեղական պահեստավորման այս կամ այն ​​դասը, պետք է ուղղվեն միայն այս կամ այն ​​հանգույցներին՝ օգտագործելով պիտակներ: Այս նպատակների համար օպերատորը կարող է նշանակել ինչ-որ պիտակ և մեկ հյուրընկալող օրինակ: Եվ պարզվում է, որ pods-ը կուղարկվի Kubernetes-ի կողմից, որպեսզի աշխատեն միայն այն հանգույցների վրա, որոնք բավարարում են պահանջները, պիտակները, պարզ բառերով: Ադմինիստրատորները պիտակներ և տրամադրում են սկավառակներ ձեռքով: Եվ հետո այն մասշտաբներով:

Եվ դա երրորդ տարբերակն է, տեղական, որն օգնում է դա մի փոքր ավելի հեշտ դարձնել: Ինչպես արդեն ընդգծել եմ, սա թյունինգի վրա տքնաջան աշխատանք է, որն ի վերջո օգնում է առավելագույն կատարողականություն ձեռք բերել:

Սրա հետ կապված երկրորդ հարց ունեմ. Kubernetes-ը նախագծվել է այնպես, որ մեզ համար նշանակություն չունի՝ մենք կորցնում ենք հանգույց, թե ոչ։ Ի՞նչ պետք է անենք այս դեպքում, եթե կորցրել ենք այն հանգույցը, որտեղ կախված է մեր բեկորը:

Այո, Kubernetes-ը ի սկզբանե գտնում էր, որ մեր կապը մեր պատիճների հետ նման է անասունի, բայց այստեղ մեզ մոտ յուրաքանչյուր սկավառակ դառնում է ընտանի կենդանու նման մի բան: Այնպիսի խնդիր կա, որ մենք չենք կարող դրանք ուղղակի դեն նետել։ Իսկ Kubernetes-ի զարգացումը գնում է այն ուղղությամբ, որ անհնար է ամբողջությամբ վերաբերվել փիլիսոփայորեն, կարծես այն ամբողջովին դեն նետված ռեսուրս է։

Հիմա գործնական հարցի համար. Ի՞նչ անել, եթե կորցրել եք այն հանգույցը, որի վրա գտնվում էր սկավառակը: Այստեղ խնդիրը լուծվում է ավելի բարձր մակարդակով։ ClickHouse-ի դեպքում մենք ունենք կրկնօրինակներ, որոնք աշխատում են ավելի բարձր մակարդակով, այսինքն. ClickHouse մակարդակում:

Ո՞րն է արդյունքում ստացված տրամադրությունը: DevOps-ը պատասխանատու է տվյալների չկորցնելու համար: Նա պետք է ճիշտ կարգավորի կրկնօրինակումը և պետք է ապահովի, որ կրկնօրինակումն աշխատում է: ClickHouse մակարդակի կրկնօրինակը պետք է կրկնօրինակված տվյալներ ունենա: Սա այն խնդիրը չէ, որ լուծում է օպերատորը։ Եվ ոչ այն խնդիրը, որն ինքը լուծում է Kubernetes-ը։ Սա ClickHouse մակարդակում է:

Ի՞նչ անել, եթե ձեր երկաթե հանգույցն ընկնի: Եվ պարզվում է, որ ձեզ հարկավոր է տեղադրել երկրորդը, պատշաճ կերպով ապահովել սկավառակը դրա վրա և կիրառել պիտակներ: Եվ դրանից հետո այն կհամապատասխանի այն պահանջներին, որ Kubernetes-ը կարող է գործարկել դրա վրա օրինակների pod: Kubernetes-ը կգործարկի այն: Ձեր պատյանների քանակը բավարար չէ նշված թվին բավարարելու համար: Դա կանցնի այն ցիկլով, որը ես ցույց տվեցի։ Իսկ ամենաբարձր մակարդակով ClickHouse-ը կհասկանա, որ մենք մուտքագրել ենք կրկնօրինակ, այն դեռ դատարկ է, և մենք պետք է սկսենք տվյալներ փոխանցել դրան։ Նրանք. Այս գործընթացը դեռ լավ ավտոմատացված չէ:

Շնորհակալություն զեկույցի համար: Երբ ամենատարբեր տհաճ բաներ են տեղի ունենում, օպերատորը խափանում է և վերագործարկվում, և այդ պահին իրադարձություններ են գալիս, ինչ-որ կերպ կառավարո՞ւմ եք դա:

Ի՞նչ կլինի, եթե օպերատորը վթարի ենթարկվի և վերագործարկվի, ճիշտ է:

Այո՛։ Եվ այդ պահին իրադարձությունները եկան.

Այս դեպքում անելիքների խնդիրը մասամբ կիսվում է օպերատորի և Kubernetes-ի միջև: Kubernetes-ն ունի տեղի ունեցած իրադարձությունը վերարտադրելու ունակություն: Նա կրկնում է. Եվ օպերատորի խնդիրն է համոզվել, որ երբ իրադարձությունների մատյանը վերարտադրվում է իր վրա, այդ իրադարձությունները անզոր են: Եվ որպեսզի նույն իրադարձության կրկնվող դեպքերը չկոտրեն մեր համակարգը։ Եվ մեր օպերատորը հաղթահարում է այս խնդիրը:

Բարեւ Ձեզ! Շնորհակալություն զեկույցի համար: Դմիտրի Զավյալով, ընկերություն Սմեդովան. Ծրագրեր կա՞ն օպերատորին ավելացնել հապրոքսիով կարգավորելու հնարավորությունը: Ինձ կհետաքրքրի ստանդարտից բացի մեկ այլ հավասարակշռող, որպեսզի այն խելացի լինի և հասկանա, որ ClickHouse-ը իսկապես կա:

Ինգրեսի մասին ես խոսում?

Այո, փոխարինեք Ingress-ը հապրոքսիով: Հապրոքսիայում դուք կարող եք նշել կլաստերի տոպոլոգիան, որտեղ այն ունի կրկնօրինակներ:

Մենք դեռ չենք մտածել այդ մասին։ Եթե ​​դա ձեզ անհրաժեշտ է և կարող եք բացատրել, թե ինչու է դա անհրաժեշտ, ապա հնարավոր կլինի այն իրականացնել, հատկապես, եթե ցանկանում եք մասնակցել։ Մենք ուրախ կլինենք դիտարկել տարբերակը: Կարճ պատասխանն է՝ ոչ, մենք ներկայումս չունենք նման ֆունկցիոնալություն։ Շնորհակալություն հուշման համար, մենք կքննարկենք այս հարցը: Եվ եթե դուք նաև բացատրեք օգտագործման դեպքը և ինչու է դա անհրաժեշտ գործնականում, օրինակ, խնդիրներ ստեղծեք GitHub-ում, ապա դա հիանալի կլինի:

Արդեն ունի.

Լավ: Մենք բաց ենք ցանկացած առաջարկի համար։ Իսկ հապրոքսին ավելացվում է անելիքների ցանկին: Todo ցուցակն աճում է, դեռ չի կրճատվում: Բայց սա լավ է, նշանակում է, որ ապրանքը պահանջարկ ունի։

Source: www.habr.com