Ողջույն, Habr!
Ժամանակին մենք առաջինն էինք, որ թեման ներմուծեցինք ռուսական շուկա
Ներածություն
Kubernetes-ը նախատեսված է առանց քաղաքացիության աշխատանքային ծանրաբեռնվածությունը կարգավորելու համար: Սովորաբար, նման ծանրաբեռնվածությունը ներկայացվում է միկրոսերվիսային ճարտարապետության տեսքով, դրանք թեթև են, լավ չափվում են հորիզոնական, հետևում են 12 գործոնային հավելվածների սկզբունքներին և կարող են աշխատել անջատիչների և քաոսի կապիկների հետ:
Կաֆկան, մյուս կողմից, ըստ էության գործում է որպես բաշխված տվյալների բազա։ Այսպիսով, աշխատելիս պետք է գործ ունենալ պետության հետ, և դա շատ ավելի ծանր է, քան միկրոսերվիսը։ Kubernetes-ն աջակցում է պետական բեռներ, բայց ինչպես նշում է Kelsey Hightower-ը երկու թվիթերում, դրանք պետք է զգույշ վարվեն.
Ոմանք կարծում են, որ եթե Kubernetes-ը տեղափոխեք պետական ծանրաբեռնվածություն, այն դառնում է ամբողջությամբ կառավարվող տվյալների բազա, որը մրցակից է RDS-ին: Սա սխալ է. Միգուցե, եթե բավականաչափ աշխատեք, ավելացնեք լրացուցիչ բաղադրիչներ և ներգրավեք SRE ինժեներների թիմ, կկարողանաք կառուցել RDS Kubernetes-ի վերևում:
Ես միշտ խորհուրդ եմ տալիս բոլորին ծայրահեղ զգույշ լինել Kubernetes-ում պետական ծանրաբեռնվածություն գործարկելիս: Մարդկանց մեծամասնությունը, ովքեր հարցնում են՝ «կարո՞ղ եմ պետական աշխատանքային բեռներ գործարկել Kubernetes-ում», չունեն բավարար փորձ Kubernetes-ի հետ, և հաճախ այն ծանրաբեռնվածության հետ, որի մասին նրանք հարցնում են:
Այսպիսով, դուք պետք է աշխատեք Kafka-ն Kubernetes-ով: Հակառակ հարց. Կաֆկան ավելի լավ կաշխատի առանց Kubernetes-ի: Ահա թե ինչու ես ուզում եմ այս հոդվածում ընդգծել, թե ինչպես են Կաֆկան և Կուբերնետեսը լրացնում միմյանց, և ինչ որոգայթներ կարող են լինել դրանք համատեղելը:
Ավարտման ժամանակը
Եկեք խոսենք հիմնական բանի մասին՝ ինքնին գործարկման միջավայրը
պրոցես
Kafka բրոքերները CPU-ի համար հարմար են: TLS-ը կարող է ներդնել որոշակի գերավճար: Այնուամենայնիվ, Kafka-ի հաճախորդները կարող են ավելի ինտենսիվ պրոցեսորային լինել, եթե նրանք օգտագործում են կոդավորումը, բայց դա չի ազդում բրոքերների վրա:
հիշողություն
Կաֆկայի բրոքերները խժռում են հիշողությունը. JVM-ի կույտի չափը սովորաբար սահմանափակվում է 4-5 ԳԲ-ով, բայց ձեզ նույնպես շատ համակարգային հիշողություն է պետք, քանի որ Կաֆկան շատ է օգտագործում էջի քեշը: Kubernetes-ում սահմանեք կոնտեյների ռեսուրսներ և համապատասխանաբար պահանջեք սահմանաչափեր:
Տվյալների պահեստ
Կոնտեյներներում տվյալների պահպանումը ժամանակավոր է. տվյալները կորչում են վերագործարկման ժամանակ: Կաֆկայի տվյալների համար կարող եք օգտագործել հատոր emptyDir
, և էֆեկտը նման կլինի. ձեր բրոքերի տվյալները կկորչեն ավարտից հետո: Ձեր հաղորդագրությունները դեռևս կարող են պահվել այլ բրոքերներում՝ որպես կրկնօրինակներ: Հետևաբար, վերագործարկումից հետո ձախողված բրոքերը նախ պետք է կրկնօրինակի բոլոր տվյալները, և այս գործընթացը կարող է շատ ժամանակ տևել:
Ահա թե ինչու դուք պետք է օգտագործեք տվյալների երկարաժամկետ պահեստավորում: Թող դա լինի ոչ տեղական երկարաժամկետ պահեստավորում XFS ֆայլային համակարգով կամ, ավելի ճիշտ, ext4: Մի օգտագործեք NFS: Ես քեզ զգուշացրեցի. NFS-ի v3 կամ v4 տարբերակները չեն աշխատի: Մի խոսքով, Kafka բրոքերը կխափանվի, եթե չկարողանա ջնջել տվյալների գրացուցակը NFS-ում «հիմար վերանվանման» խնդրի պատճառով: Եթե դեռ չեմ համոզել, շատ ուշադիր
Сеть
Ինչպես բաշխված համակարգերի մեծ մասի դեպքում, Կաֆկայի կատարումը մեծապես կախված է ցանցի հետաձգումը նվազագույնի, իսկ թողունակությունը առավելագույնի հասցնելուց: Մի փորձեք հյուրընկալել բոլոր բրոքերներին նույն հանգույցում, քանի որ դա կնվազեցնի հասանելիությունը: Եթե Kubernetes հանգույցը ձախողվի, ամբողջ Կաֆկա կլաստերը կձախողվի: Նաև մի ցրեք Կաֆկա կլաստերը տվյալների ամբողջ կենտրոններում: Նույնը վերաբերում է Kubernetes կլաստերին: Այս դեպքում լավ փոխզիջում է մատչելիության տարբեր գոտիներ ընտրելը:
Տեսիլ
Հերթական մանիֆեստներ
Kubernetes կայքը ունի
- UnderՊոդը Kubernetes-ում ամենափոքր տեղակայվող միավորն է: Փոդը պարունակում է ձեր աշխատանքային ծանրաբեռնվածությունը, և պատիճն ինքնին համապատասխանում է ձեր կլաստերի գործընթացին: Փայտը պարունակում է մեկ կամ մի քանի տարա: Յուրաքանչյուր ZooKeeper սերվեր անսամբլի մեջ և յուրաքանչյուր բրոքեր Կաֆկա կլաստերում կաշխատեն առանձին պատիճով:
- StatefulSetStatefulSet-ը Kubernetes-ի օբյեկտ է, որը կառավարում է մի քանի վիճակագրական աշխատանքային բեռներ, և այդպիսի ծանրաբեռնվածությունները պահանջում են համակարգում: StatefulSets-ը երաշխիքներ է տրամադրում պատիճների պատվիրման և դրանց յուրահատկության վերաբերյալ:
- Անգլուխ ծառայություններԾառայությունները թույլ են տալիս բաժանել պատյանները հաճախորդներից՝ օգտագործելով տրամաբանական անուն: Kubernetes-ն այս դեպքում պատասխանատու է բեռի հավասարակշռման համար: Այնուամենայնիվ, երբ աշխատում են պետական աշխատանքային ծանրաբեռնվածություններ, ինչպիսիք են ZooKeeper-ը և Kafka-ն, հաճախորդները պետք է շփվեն կոնկրետ օրինակի հետ: Այստեղ է, որ անգլուխ ծառայություններն օգտակար են. այս դեպքում հաճախորդը դեռևս կունենա տրամաբանական անուն, բայց դուք ստիպված չեք լինի ուղղակիորեն կապվել պատի հետ:
- Երկարաժամկետ պահպանման ծավալըԱյս ծավալներն անհրաժեշտ են վերը նշված ոչ լոկալ բլոկային կայուն պահեստը կարգավորելու համար:
On
Սաղավարտի գծապատկերներ
Helm-ը Kubernetes-ի փաթեթների կառավարիչ է, որը կարելի է համեմատել OS փաթեթների կառավարիչների հետ, ինչպիսիք են yum, apt, Homebrew կամ Chocolatey: Այն հեշտացնում է Helm գծապատկերներում նկարագրված նախապես սահմանված ծրագրային փաթեթների տեղադրումը: Լավ ընտրված Helm աղյուսակը հեշտացնում է դժվարին խնդիրը՝ ինչպես ճիշտ կարգավորել բոլոր պարամետրերը՝ Kafka-ն Kubernetes-ում օգտագործելու համար: Կան մի քանի Կաֆկայի դիագրամներ՝ պաշտոնականը գտնվում է
Օպերատորներ
Քանի որ Helm-ն ունի որոշակի թերություններ, մեկ այլ գործիք է ձեռք բերում զգալի ժողովրդականություն՝ Kubernetes օպերատորներ: Օպերատորը ոչ միայն փաթեթավորում է ծրագրակազմ Kubernetes-ի համար, այլ նաև թույլ է տալիս տեղակայել այդպիսի ծրագրակազմ և կառավարել այն։
ցանկը
Արտադրողականություն
Կարևոր է ստուգել կատարողականությունը՝ համեմատելով ձեր Կաֆկայի օրինակը: Նման թեստերը կօգնեն ձեզ գտնել պոտենցիալ խոչընդոտները՝ նախքան խնդիրների առաջացումը: Բարեբախտաբար, Կաֆկան արդեն տրամադրում է կատարողականության փորձարկման երկու գործիք. kafka-producer-perf-test.sh
и kafka-consumer-perf-test.sh
. Ակտիվ օգտագործեք դրանք: Հղման համար կարող եք հղում կատարել նկարագրված արդյունքներին
գործողությունները
Մոնիտորինգ
Համակարգում թափանցիկությունը շատ կարևոր է, հակառակ դեպքում դուք չեք հասկանա, թե ինչ է կատարվում դրանում: Այսօր կա ամուր գործիքակազմ, որն ապահովում է չափումների վրա հիմնված մոնիտորինգ ամպի բնիկ ոճով: Այս նպատակով երկու հայտնի գործիքներն են Պրոմեթևսը և Գրաֆանան: Պրոմեթևսը կարող է հավաքել չափումներ Java-ի բոլոր գործընթացներից (Kafka, Zookeeper, Kafka Connect)՝ օգտագործելով JMX արտահանողը՝ ամենապարզ ձևով: Եթե ավելացնեք cAdvisor չափումներ, կարող եք ավելի լիարժեք հասկանալ, թե ինչպես են ռեսուրսներն օգտագործվում Kubernetes-ում:
Strimzi-ն ունի Grafana վահանակի շատ հարմար օրինակ Կաֆկայի համար: Այն պատկերացնում է հիմնական չափումները, օրինակ՝ քիչ կրկնվող հատվածների կամ անցանց հատվածների մասին: Այնտեղ ամեն ինչ շատ պարզ է։ Այս ցուցանիշները լրացվում են ռեսուրսների օգտագործման և կատարողականի մասին տեղեկատվությամբ, ինչպես նաև կայունության ցուցանիշներով: Այսպիսով, դուք ստանում եք հիմնական Կաֆկա կլաստերի մոնիտորինգը ոչ մի բանի համար:
Source:
Լավ կլինի այս ամենը լրացնել հաճախորդի մոնիտորինգով (չափանիշներ սպառողների և արտադրողների վրա), ինչպես նաև ուշացման մոնիտորինգով (դրա համար կա
անտառահատումներ
Մուտքագրումը ևս մեկ կարևոր խնդիր է: Համոզվեք, որ ձեր Kafka-ի տեղադրման բոլոր բեռնարկղերը մուտք են գործել stdout
и stderr
, և նաև համոզվեք, որ ձեր Kubernetes կլաստերը համախմբում է բոլոր տեղեկամատյանները կենտրոնական գրանցման ենթակառուցվածքում, օրինակ.
Առողջության ստուգում
Kubernetes-ն օգտագործում է աշխուժության և պատրաստակամության զոնդեր՝ ստուգելու, թե արդյոք ձեր պատիճները նորմալ են աշխատում: Եթե ակտիվության ստուգումը ձախողվի, Kubernetes-ը կդադարեցնի այդ բեռնարկղը և այնուհետև ավտոմատ կերպով կվերագործարկի այն, եթե համապատասխանաբար սահմանված է վերագործարկման քաղաքականությունը: Եթե պատրաստության ստուգումը ձախողվի, Kubernetes-ը մեկուսացնում է պատիճը սպասարկման հարցումներից: Այսպիսով, նման դեպքերում ձեռքով միջամտություն ընդհանրապես չի պահանջվում, ինչը մեծ պլյուս է։
Թարմացումների տարածում
StatefulSets-ն աջակցում է ավտոմատ թարմացումներին. եթե ընտրեք RollingUpdate ռազմավարությունը, Kafka-ի տակ գտնվող յուրաքանչյուրը հերթով կթարմացվի: Այսպիսով, պարապուրդի ժամանակը կարող է կրճատվել մինչև զրոյի:
Scaling
Կաֆկայի կլաստերի չափումը հեշտ գործ չէ: Այնուամենայնիվ, Kubernetes-ը շատ հեշտ է դարձնում պատիճները որոշակի թվով կրկնօրինակների մասշտաբը, ինչը նշանակում է, որ դուք կարող եք դեկլարատիվ կերպով սահմանել այնքան Kafka բրոքերներ, որքան ցանկանում եք: Այս դեպքում ամենադժվարը սեկտորների վերանշանակումն է մեծացումից հետո կամ փոքրացնելուց առաջ: Կրկին, Kubernetes-ը կօգնի ձեզ այս առաջադրանքում:
Վարչակազմը
Ձեր Kafka կլաստերի կառավարման հետ կապված առաջադրանքները, ինչպիսիք են թեմաների ստեղծումը և հատվածների վերանշանակումը, կարող են կատարվել՝ օգտագործելով գոյություն ունեցող shell սկրիպտները՝ բացելով հրամանի տողի ինտերֆեյսը ձեր պատյաններում: Այնուամենայնիվ, այս լուծումը այնքան էլ գեղեցիկ չէ: Strimzi-ն աջակցում է թեմաների կառավարմանը՝ օգտագործելով այլ օպերատոր: Այստեղ բարելավման որոշակի տեղ կա:
Կրկնօրինակեք և վերականգնեք
Այժմ Kafka-ի հասանելիությունը կախված կլինի նաև Kubernetes-ի առկայությունից։ Եթե ձեր Kubernetes կլաստերը ձախողվի, ապա վատագույն դեպքում ձեր Կաֆկա կլաստերը նույնպես կձախողվի: Մերֆիի օրենքի համաձայն, դա անպայման տեղի կունենա, և դուք կկորցնեք տվյալները: Այս տեսակի ռիսկերը նվազեցնելու համար լավ պահուստային հայեցակարգ ունեցեք: Դուք կարող եք օգտագործել MirrorMaker-ը, մեկ այլ տարբերակ՝ դրա համար օգտագործել S3-ը, ինչպես նկարագրված է սրա համար
Ամփոփում
Փոքր և միջին չափի Kafka կլաստերների հետ աշխատելիս միանշանակ արժե օգտագործել Kubernetes-ը, քանի որ այն ապահովում է լրացուցիչ ճկունություն և հեշտացնում է օպերատորի փորձը: Եթե դուք ունեք շատ նշանակալի ոչ ֆունկցիոնալ հետաձգման և/կամ թողունակության պահանջներ, ապա ավելի լավ կլինի դիտարկել տեղակայման որևէ այլ տարբերակ:
Source: www.habr.com