Կաֆկան Kubernetes-ում լավն է:

Ողջույն, Habr!

Ժամանակին մենք առաջինն էինք, որ թեման ներմուծեցինք ռուսական շուկա Kafka և շարունակիր հետեւեք դրա զարգացման համար։ Մասնավորապես, մենք գտանք Կաֆկայի փոխազդեցության թեման և Կուբերնետես. Դիտելի (և բավականին զգույշ) հոդված այս թեման հրապարակվել է Confluent բլոգում դեռ անցյալ տարվա հոկտեմբերին՝ Գվեն Շապիրայի հեղինակությամբ։ Այսօր մենք ցանկանում ենք ձեր ուշադրությունը հրավիրել Յոհան Գայգերի ապրիլյան ավելի նոր հոդվածի վրա, ով թեև վերնագրում առանց հարցականի չէ, բայց թեման ավելի բովանդակալից է քննում՝ ուղեկցելով տեքստը հետաքրքիր հղումներով։ Խնդրում ենք ներել մեզ «քաոս կապիկ» անվճար թարգմանությունը, եթե կարող եք:

Ներածություն

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 կլաստերին: Այս դեպքում լավ փոխզիջում է մատչելիության տարբեր գոտիներ ընտրելը:

Տեսիլ

Հերթական մանիֆեստներ

Kubernetes կայքը ունի շատ լավ ուղեցույց այն մասին, թե ինչպես կարգավորել ZooKeeper-ը՝ օգտագործելով մանիֆեստները: Քանի որ ZooKeeper-ը Kafka-ի մի մասն է, սա լավ տեղ է սկսելու ծանոթանալու, թե որ Kubernetes-ի հայեցակարգերը կիրառվում են այստեղ: Սա հասկանալուց հետո դուք կարող եք օգտագործել նույն հասկացությունները Կաֆկայի կլաստերի հետ:

• UnderՊոդը Kubernetes-ում ամենափոքր տեղակայվող միավորն է: Փոդը պարունակում է ձեր աշխատանքային ծանրաբեռնվածությունը, և պատիճն ինքնին համապատասխանում է ձեր կլաստերի գործընթացին: Փայտը պարունակում է մեկ կամ մի քանի տարա: Յուրաքանչյուր ZooKeeper սերվեր անսամբլի մեջ և յուրաքանչյուր բրոքեր Կաֆկա կլաստերում կաշխատեն առանձին պատիճով:
• StatefulSetStatefulSet-ը Kubernetes-ի օբյեկտ է, որը կառավարում է մի քանի վիճակագրական աշխատանքային բեռներ, և այդպիսի ծանրաբեռնվածությունները պահանջում են համակարգում: StatefulSets-ը երաշխիքներ է տրամադրում պատիճների պատվիրման և դրանց յուրահատկության վերաբերյալ:
• Անգլուխ ծառայություններԾառայությունները թույլ են տալիս բաժանել պատյանները հաճախորդներից՝ օգտագործելով տրամաբանական անուն: Kubernetes-ն այս դեպքում պատասխանատու է բեռի հավասարակշռման համար: Այնուամենայնիվ, երբ աշխատում են պետական ​​աշխատանքային ծանրաբեռնվածություններ, ինչպիսիք են ZooKeeper-ը և Kafka-ն, հաճախորդները պետք է շփվեն կոնկրետ օրինակի հետ: Այստեղ է, որ անգլուխ ծառայություններն օգտակար են. այս դեպքում հաճախորդը դեռևս կունենա տրամաբանական անուն, բայց դուք ստիպված չեք լինի ուղղակիորեն կապվել պատի հետ:
• Երկարաժամկետ պահպանման ծավալըԱյս ծավալներն անհրաժեշտ են վերը նշված ոչ լոկալ բլոկային կայուն պահեստը կարգավորելու համար:

On Յոլեան Տրամադրում է մանիֆեստների համապարփակ փաթեթ, որը կօգնի ձեզ սկսել Kafka-ի հետ Kubernetes-ում:

Սաղավարտի գծապատկերներ

Helm-ը Kubernetes-ի փաթեթների կառավարիչ է, որը կարելի է համեմատել OS փաթեթների կառավարիչների հետ, ինչպիսիք են yum, apt, Homebrew կամ Chocolatey: Այն հեշտացնում է Helm գծապատկերներում նկարագրված նախապես սահմանված ծրագրային փաթեթների տեղադրումը: Լավ ընտրված Helm աղյուսակը հեշտացնում է դժվարին խնդիրը՝ ինչպես ճիշտ կարգավորել բոլոր պարամետրերը՝ Kafka-ն Kubernetes-ում օգտագործելու համար: Կան մի քանի Կաֆկայի դիագրամներ՝ պաշտոնականը գտնվում է ինկուբատոր վիճակում, կա մեկը Հանգույց, ևս մեկ - ից BitNami.

Օպերատորներ

Քանի որ Helm-ն ունի որոշակի թերություններ, մեկ այլ գործիք է ձեռք բերում զգալի ժողովրդականություն՝ Kubernetes օպերատորներ: Օպերատորը ոչ միայն փաթեթավորում է ծրագրակազմ Kubernetes-ի համար, այլ նաև թույլ է տալիս տեղակայել այդպիսի ծրագրակազմ և կառավարել այն։

ցանկը զարմանալի օպերատորներ Կաֆկայի համար նշվում են երկու օպերատորներ. Նրանցից մեկը - Ստրիմզի. Strimzi-ի միջոցով հեշտ է մի քանի րոպեում գործարկել ձեր Kafka կլաստերը: Գործնականում ոչ մի կոնֆիգուրացիա չի պահանջվում, բացի այդ, օպերատորն ինքն է ապահովում մի քանի գեղեցիկ հնարավորություններ, օրինակ՝ կետ առ կետ TLS կոդավորումը կլաստերի ներսում: Confluent-ը նաև ապահովում է սեփական օպերատոր.

Արտադրողականություն

Կարևոր է ստուգել կատարողականությունը՝ համեմատելով ձեր Կաֆկայի օրինակը: Նման թեստերը կօգնեն ձեզ գտնել պոտենցիալ խոչընդոտները՝ նախքան խնդիրների առաջացումը: Բարեբախտաբար, Կաֆկան արդեն տրամադրում է կատարողականության փորձարկման երկու գործիք. kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Ակտիվ օգտագործեք դրանք: Հղման համար կարող եք հղում կատարել նկարագրված արդյունքներին այս գրառումը Jay Kreps, կամ կենտրոնանալ այս վերանայումը Amazon MSK Ստեֆան Մաարեկի կողմից:

գործողությունները

Մոնիտորինգ

Համակարգում թափանցիկությունը շատ կարևոր է, հակառակ դեպքում դուք չեք հասկանա, թե ինչ է կատարվում դրանում: Այսօր կա ամուր գործիքակազմ, որն ապահովում է չափումների վրա հիմնված մոնիտորինգ ամպի բնիկ ոճով: Այս նպատակով երկու հայտնի գործիքներն են Պրոմեթևսը և Գրաֆանան: Պրոմեթևսը կարող է հավաքել չափումներ Java-ի բոլոր գործընթացներից (Kafka, Zookeeper, Kafka Connect)՝ օգտագործելով JMX արտահանողը՝ ամենապարզ ձևով: Եթե ​​ավելացնեք cAdvisor չափումներ, կարող եք ավելի լիարժեք հասկանալ, թե ինչպես են ռեսուրսներն օգտագործվում Kubernetes-ում:

Strimzi-ն ունի Grafana վահանակի շատ հարմար օրինակ Կաֆկայի համար: Այն պատկերացնում է հիմնական չափումները, օրինակ՝ քիչ կրկնվող հատվածների կամ անցանց հատվածների մասին: Այնտեղ ամեն ինչ շատ պարզ է։ Այս ցուցանիշները լրացվում են ռեսուրսների օգտագործման և կատարողականի մասին տեղեկատվությամբ, ինչպես նաև կայունության ցուցանիշներով: Այսպիսով, դուք ստանում եք հիմնական Կաֆկա կլաստերի մոնիտորինգը ոչ մի բանի համար:

Source: streamzi.io/docs/master/#kafka_dashboard

Լավ կլինի այս ամենը լրացնել հաճախորդի մոնիտորինգով (չափանիշներ սպառողների և արտադրողների վրա), ինչպես նաև ուշացման մոնիտորինգով (դրա համար կա Burrow) և վերջից մինչև վերջ մոնիտորինգ՝ այս օգտագործման համար Կաֆկա մոնիտոր.

անտառահատումներ

Մուտքագրումը ևս մեկ կարևոր խնդիր է: Համոզվեք, որ ձեր Kafka-ի տեղադրման բոլոր բեռնարկղերը մուտք են գործել stdout и stderr, և նաև համոզվեք, որ ձեր Kubernetes կլաստերը համախմբում է բոլոր տեղեկամատյանները կենտրոնական գրանցման ենթակառուցվածքում, օրինակ. Elasticsearch- ը.

Առողջության ստուգում

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

Թարմացումների տարածում

StatefulSets-ն աջակցում է ավտոմատ թարմացումներին. եթե ընտրեք RollingUpdate ռազմավարությունը, Kafka-ի տակ գտնվող յուրաքանչյուրը հերթով կթարմացվի: Այսպիսով, պարապուրդի ժամանակը կարող է կրճատվել մինչև զրոյի:

Scaling

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

Վարչակազմը

Ձեր Kafka կլաստերի կառավարման հետ կապված առաջադրանքները, ինչպիսիք են թեմաների ստեղծումը և հատվածների վերանշանակումը, կարող են կատարվել՝ օգտագործելով գոյություն ունեցող shell սկրիպտները՝ բացելով հրամանի տողի ինտերֆեյսը ձեր պատյաններում: Այնուամենայնիվ, այս լուծումը այնքան էլ գեղեցիկ չէ: Strimzi-ն աջակցում է թեմաների կառավարմանը՝ օգտագործելով այլ օպերատոր: Այստեղ բարելավման որոշակի տեղ կա:

Կրկնօրինակեք և վերականգնեք

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

Ամփոփում

Փոքր և միջին չափի Kafka կլաստերների հետ աշխատելիս միանշանակ արժե օգտագործել Kubernetes-ը, քանի որ այն ապահովում է լրացուցիչ ճկունություն և հեշտացնում է օպերատորի փորձը: Եթե ​​դուք ունեք շատ նշանակալի ոչ ֆունկցիոնալ հետաձգման և/կամ թողունակության պահանջներ, ապա ավելի լավ կլինի դիտարկել տեղակայման որևէ այլ տարբերակ:

Source: www.habr.com