Дали е добар Кафка на Кубернетис?

Поздрав, Хабр!

Едно време, први ја воведовме темата на рускиот пазар Кафка и продолжи патеката за нејзиниот развој. Конкретно, ја најдовме темата за интеракцијата помеѓу Кафка и Кубернети. Забележливо (и прилично внимателно) Член оваа тема беше објавена на блогот Confluent уште во октомври минатата година под авторство на Гвен Шапира. Денес би сакале да ви го свртиме вниманието на една понова статија од април на Јохан Гигер, кој иако не е без прашалник во насловот, ја разгледува темата на посуштински начин, придружувајќи го текстот со интересни врски. Простете ни го бесплатниот превод на „хаос мајмун“ ако можете!

Вовед

Kubernetes е дизајниран да се справи со оптоварувањата без државјанство. Вообичаено, таквите оптоварувања се претставени во форма на архитектура на микросервис, тие се лесни, добро се размеруваат хоризонтално, ги следат принципите на апликациите од 12 фактори и можат да работат со прекинувачи и хаос мајмуни.

Кафка, од друга страна, во суштина делува како дистрибуирана база на податоци. Така, кога работите, треба да се занимавате со држава, а таа е многу потешка од микросервис. Kubernetes поддржува државни товари, но како што истакнува Келси Хајтауер во два твита, со нив треба да се постапува внимателно:

Некои луѓе сметаат дека ако го префрлите Kubernetes во државен обем на работа, тој станува целосно управувана база на податоци што му се спротивставува на RDS. Ова е погрешно. Можеби, ако работите доволно напорно, додадете дополнителни компоненти и привлечете тим од инженери на SRE, ќе можете да изградите RDS на врвот на Kubernetes.

Секогаш им препорачувам на сите да бидат крајно претпазливи кога извршуваат оптоварувања со статус на Kubernetes. Повеќето луѓе кои прашуваат „дали можам да извршувам државни оптоварувања на Kubernetes“ немаат доволно искуство со Kubernetes, а често и со обемот на работа за кој прашуваат.

Значи, дали треба да го водите Кафка на Кубернетес? Контра прашање: дали Кафка ќе работи подобро без Кубернетис? Затоа сакам во оваа статија да истакнам како Кафка и Кубернетес се надополнуваат еден со друг и какви замки може да дојде со нивното комбинирање.

Време на завршување

Ајде да зборуваме за основната работа - самата средина за извршување

процес

Брокерите на Кафка се пријателски настроени кон процесорот. TLS може да воведе некои трошоци. Сепак, клиентите на Кафка може да бидат поинтензивни на процесорот ако користат шифрирање, но тоа не влијае на брокерите.

меморија

Брокерите на Кафка ја јадат меморијата. Големината на купот на JVM обично е ограничена на 4-5 GB, но ќе ви треба и многу системска меморија бидејќи Кафка многу го користи кешот на страницата. Во Kubernetes, поставете ресурс за контејнери и соодветно побарајте ограничувања.

Складирање на податоци

Складирањето податоци во контејнери е ефемерно - податоците се губат при рестартирање. За податоците за Кафка можете да користите волумен emptyDir, а ефектот ќе биде сличен: вашите податоци за брокерот ќе бидат изгубени по завршувањето. Вашите пораки сè уште може да се складираат на други брокери како реплики. Затоа, по рестартирање, неуспешниот брокер прво мора да ги реплицира сите податоци и овој процес може да потрае многу време.

Ова е причината зошто треба да користите долгорочно складирање податоци. Нека биде нелокално долгорочно складирање со датотечен систем XFS или, поточно, ext4. Не користете NFS. Те предупредив. Верзиите на NFS v3 или v4 нема да работат. Накратко, брокерот Кафка ќе падне ако не може да го избрише директориумот со податоци поради проблемот со „глупаво преименување“ во NFS. Ако сè уште не сум те убедил, многу внимателно прочитајте ја оваа статија. Продавницата за податоци треба да биде нелокална, така што Kubernetes може пофлексибилно да избере нов јазол по рестартирање или преместување.

Мрежа

Како и кај повеќето дистрибуирани системи, перформансите на Кафка се многу зависни од одржувањето на латентноста на мрежата на минимум и пропусниот опсег да се максимизира. Не обидувајте се да ги хостирате сите брокери на истиот јазол, бидејќи тоа ќе ја намали достапноста. Ако не успее јазолот на Кубернет, ќе пропадне целиот кластер на Кафка. Исто така, не го расфрлајте кластерот Кафка низ цели центри за податоци. Истото важи и за кластерот Кубернетес. Добар компромис во овој случај е да се изберат различни зони на достапност.

Конфигурација

Редовни манифести

Веб-страницата Кубернетес има многу добар водич за тоа како да го конфигурирате ZooKeeper користејќи манифести. Бидејќи ZooKeeper е дел од Кафка, ова е добро место за почеток да се запознаете со кои концепти на Кубернетес се применуваат овде. Откако ќе го разберете ова, можете да ги користите истите концепти со кластерот Кафка.

• Под: pod е најмалата распоредлива единица во Kubernetes. Подлогата го содржи вашиот обем на работа, а самиот подлога одговара на процес во вашиот кластер. Мешунката содржи еден или повеќе контејнери. Секој ZooKeeper сервер во ансамблот и секој брокер во кластерот Кафка ќе работат во посебна подлога.
• StatefulSet: StatefulSet е објект на Kubernetes што се справува со повеќе работни оптоварувања со статус, и таквите оптоварувања бараат координација. StatefulSets обезбедуваат гаранции во врска со нарачката на мешунките и нивната уникатност.
• Служби без глава: Услугите ви дозволуваат да одвојувате подлоги од клиенти користејќи логично име. Kubernetes во овој случај е одговорен за балансирање на товарот. Како и да е, кога работат оптоварувања со статус, како што се ZooKeeper и Kafka, клиентите треба да комуницираат со одреден пример. Овде ни се достапни услугите без глава: во овој случај, клиентот сè уште ќе има логично име, но нема да мора директно да контактирате со подлогата.
• Долгорочен волумен на складирање: Овие томови се потребни за да се конфигурира нелокалното блокирано постојано складирање споменато погоре.

На Јолеан Обезбедува сеопфатен сет на манифестации за да ви помогне да започнете со Кафка на Kubernetes.

Карти на кормила

Helm е менаџер на пакети за Kubernetes што може да се спореди со менаџери на пакети на ОС како што се yum, apt, Homebrew или Chocolatey. Тоа го олеснува инсталирањето на претходно дефинирани софтверски пакети опишани во графиконите на Helm. Добро избраната табела на Helm ја прави тешката задача како правилно да ги конфигурирате сите параметри за користење на Кафка на Kubernetes лесна. Постојат неколку дијаграми на Кафка: се наоѓа официјалниот во состојба на инкубатор, има еден од Метеж, уште еден - од Bitnami.

Оператори

Бидејќи Helm има одредени недостатоци, друга алатка добива значителна популарност: операторите Kubernetes. Операторот не само што пакува софтвер за Kubernetes, туку исто така ви овозможува да распоредите таков софтвер и да управувате со него.

Во списокот неверојатни оператори За Кафка се споменуваат два оператори. Еден од нив - Стримзи. Со Strimzi, лесно е да го активирате вашиот кластер Кафка за неколку минути. Практично не е потребна конфигурација, покрај тоа, самиот оператор обезбедува некои убави функции, на пример, TLS шифрирање од точка до точка во кластерот. Конфлуент, исто така, обезбедува сопствен оператор.

Перформанси

Важно е да ги тестирате перформансите со споредување на вашиот пример на Кафка. Ваквите тестови ќе ви помогнат да ги пронајдете потенцијалните тесни грла пред да се појават проблеми. За среќа, Кафка веќе обезбедува две алатки за тестирање на перформансите: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Искористете ги активно. За повикување, можете да се повикате на резултатите опишани во овој пост Џеј Крепс, или фокусирајте се на овој преглед Amazon MSK од Стефан Марек.

Операции

Мониторинг

Транспарентноста во системот е многу важна - во спротивно нема да разберете што се случува во него. Денес постои солидна алатка која обезбедува следење базирано на метрика во мајчин стил на облак. Две популарни алатки за оваа намена се Прометеј и Графана. Прометеј може да собира метрика од сите процеси на Јава (Kafka, Zookeeper, Kafka Connect) користејќи JMX извозник - на наједноставен начин. Ако додадете метрика на cAdvisor, можете поцелосно да разберете како се користат ресурсите во Kubernetes.

Стримзи има многу пригоден пример на Графана табла за Кафка. Ги визуелизира клучните метрики, на пример, за недоволно реплицираните сектори или оние што се офлајн. Сè е многу јасно таму. Овие метрики се надополнети со информации за искористеноста на ресурсите и перформансите, како и со индикатори за стабилност. Значи, за ништо добивате основно следење на кластерот на Кафка!

Извор: streamzi.io/docs/master/#kafka_dashboard

Би било убаво сето ова да се дополни со следење на клиентите (метрика за потрошувачите и производителите), како и следење на латентност (за ова постои закопуваат) и следење од крај до крај - за оваа употреба Кафка монитор.

Сеча

Пријавувањето е уште една критична задача. Проверете дали се најавени сите контејнери во вашата инсталација на Кафка stdout и stderr, а исто така погрижете се вашиот кластер Kubernetes да ги собира сите логови во централна инфраструктура за евиденција, на пр. Еластична пребарување.

Функционално тестирање

Kubernetes користи сонди за живост и подготвеност за да провери дали вашите мешунки работат нормално. Ако проверката на живост не успее, Kubernetes ќе го запре тој контејнер и потоа автоматски ќе го рестартира ако политиката за рестартирање е соодветно поставена. Ако проверката на подготвеноста не успее, Kubernetes го изолира подлогата од барањата за сервисирање. Така, во вакви случаи, веќе воопшто не е потребна мануелна интервенција, што е голем плус.

Воведување ажурирања

StatefulSets поддржуваат автоматски ажурирања: ако ја изберете стратегијата RollingUpdate, секое под Кафка ќе се ажурира по ред. На овој начин, времето на застој може да се намали на нула.

Скалирање

Скалирањето на кластерот Кафка не е лесна задача. Како и да е, Кубернетес го прави многу лесно скалирањето на парчињата до одреден број реплики, што значи дека можете декларативно да дефинирате онолку брокери на Кафка колку што сакате. Најтешкото нешто во овој случај е преназначувањето сектори по зголемувањето или пред намалувањето. Повторно, Kubernetes ќе ви помогне со оваа задача.

Администрација

Задачите поврзани со администрирање на вашиот кластер Кафка, како што се создавање теми и преназначување сектори, може да се направат со користење на постоечки скрипти на школка со отворање на интерфејсот на командната линија во вашите подлоги. Сепак, ова решение не е многу убаво. Strimzi поддржува управување со теми со користење на друг оператор. Има простор за подобрување овде.

Резервное копирование и востановление

Сега достапноста на Кафка ќе зависи и од достапноста на Кубернетес. Ако вашиот кластер Kubernetes не успее, тогаш во најлошото сценарио, вашиот кластер Кафка исто така ќе пропадне. Според законот на Марфи, ова дефинитивно ќе се случи, а вие ќе изгубите податоци. За да го намалите овој вид ризик, имајте добар резервен концепт. Можете да го користите MirrorMaker, друга опција е да користите S3 за ова, како што е опишано во ова пост од Заландо.

Заклучок

Кога работите со мали до средни кластери на Кафка, дефинитивно вреди да се користи Kubernetes бидејќи обезбедува дополнителна флексибилност и го поедноставува искуството на операторот. Ако имате многу значајни барања за нефункционална латентност и/или пропусната моќ, тогаш можеби е подобро да размислите за некоја друга опција за распоредување.

Извор: www.habr.com