Кубернеттегі Кафка жақсы ма?

Сәлем, Хабр!

Кезінде бұл тақырыпты Ресей нарығына бірінші болып біз енгіздік Кафка және жалғастырыңыз қадағалаңыз оның дамуы үшін. Атап айтқанда, біз Кафка мен арасындағы өзара әрекеттесу тақырыбын таптық Kubernetes. Бақыланатын (және өте мұқият) мақала бұл тақырып өткен жылдың қазан айында Гвен Шапираның авторлығымен Confluent блогында жарияланған. Бүгін біз Иоганн Гигердің сәуір айындағы соңғы мақаласына назар аударғымыз келеді, ол тақырыпта сұрақ белгісі болмаса да, мәтінді қызықты сілтемелермен сүйемелдеу арқылы тақырыпты неғұрлым мазмұнды түрде қарастырады. Мүмкіндік болса, «хаос маймылының» тегін аудармасын кешіріңіз!

Кіріспе

Kubernetes азаматтығы жоқ жұмыс жүктемелерін өңдеуге арналған. Әдетте, мұндай жұмыс жүктемелері микросервис архитектурасы түрінде ұсынылады, олар жеңіл, көлденеңінен жақсы масштабталады, 12 факторлы қолданбалардың принциптерін ұстанады және автоматты ажыратқыштармен және хаос маймылдарымен жұмыс істей алады.

Кафка, керісінше, таратылған деректер қоры ретінде әрекет етеді. Осылайша, жұмыс кезінде сіз күймен айналысуыңыз керек және бұл микросервиске қарағанда әлдеқайда ауыр. Кубернетес штаттық жүктемелерді қолдайды, бірақ Келси Хайтауэр екі твиттерде атап өткендей, оларды абайлап өңдеу керек:

Кейбір адамдар Kubernetes-ті мемлекеттік жұмыс жүктемесіне айналдырсаңыз, ол RDS-пен бәсекелесетін толық басқарылатын дерекқорға айналады деп ойлайды. Бұл олай емес. Мүмкін, егер сіз жеткілікті түрде жұмыс жасасаңыз, қосымша компоненттерді қоссаңыз және SRE инженерлерінің тобын тартсаңыз, сіз Kubernetes үстіне RDS құра аласыз.

Мен әрқашан Kubernetes жүйесінде мемлекеттік жұмыс жүктемелерін іске қосқан кезде барлығына өте сақтық танытуды ұсынамын. «Мен Kubernetes-те мемлекеттік жұмыс жүктемелерін іске қоса аламын ба» деп сұрайтын адамдардың көпшілігінде Kubernetes-те тәжірибесі жеткіліксіз және көбінесе олар сұрайтын жұмыс жүктемесі.

Сонымен, Кафканы Кубернетесте басқару керек пе? Қарсы сұрақ: Кафка Кубернетессіз жақсы жұмыс істей ме? Сондықтан мен осы мақалада Кафка мен Кубернетес бір-бірін қалай толықтыратынын және оларды біріктіру кезінде қандай қиындықтар болуы мүмкін екенін атап өткім келеді.

Аяқтау уақыты

Негізгі нәрсе - орындалу ортасының өзі туралы сөйлесейік

процесс

Кафка брокерлері процессорға ыңғайлы. TLS кейбір үстеме шығындарды енгізуі мүмкін. Дегенмен, Кафка клиенттері шифрлауды пайдаланатын болса, процессордың қарқынды болуы мүмкін, бірақ бұл брокерлерге әсер етпейді.

жад

Кафка брокерлері жадты жейді. JVM үйме өлшемі әдетте 4-5 Гбайтпен шектеледі, бірақ Кафка бет кэшін өте көп пайдаланатындықтан сізге көп жүйелік жады қажет болады. Kubernetes ішінде контейнер ресурсын орнатыңыз және сәйкесінше шектеулерді сұраңыз.

Деректер қоймасы

Контейнерлерде деректерді сақтау уақытша болып табылады - қайта іске қосылғанда деректер жоғалады. Кафка деректері үшін көлемді пайдалануға болады emptyDir, және әсер ұқсас болады: сіздің брокер деректеріңіз аяқталғаннан кейін жоғалады. Сіздің хабарламаларыңыз әлі де басқа брокерлерде көшірме ретінде сақталуы мүмкін. Сондықтан, қайта іске қосқаннан кейін, сәтсіз брокер алдымен барлық деректерді қайталауы керек және бұл процесс көп уақытты алуы мүмкін.

Сондықтан ұзақ мерзімді деректерді сақтауды пайдалану керек. Ол XFS файлдық жүйесі немесе дәлірек айтқанда ext4 арқылы жергілікті емес ұзақ мерзімді сақтау болсын. NFS қолданбаңыз. Мен саған ескерттім. NFS v3 немесе v4 нұсқалары жұмыс істемейді. Қысқаша айтқанда, NFS жүйесіндегі «атауды ақымақ өзгерту» мәселесіне байланысты деректер каталогын жоя алмаса, Кафка брокері бұзылады. Егер мен сізді әлі сендіре алмасам, өте мұқият осы мақаланы оқыңыз. Кубернетес қайта іске қосқаннан немесе орын ауыстырғаннан кейін жаңа түйінді икемді таңдай алатындай деректер қоймасы жергілікті емес болуы керек.

Желі

Көптеген таратылған жүйелердегі сияқты, Кафканың өнімділігі желінің кідірісін минималды және өткізу қабілеттілігін максималды деңгейде ұстауға байланысты. Барлық брокерлерді бір түйінде орналастыруға тырыспаңыз, себебі бұл қолжетімділікті азайтады. Кубернетес түйіні сәтсіз болса, бүкіл Кафка кластері сәтсіздікке ұшырайды. Сондай-ақ, Кафка кластерін бүкіл деректер орталықтарына таратпаңыз. Кубернетес кластеріне де солай. Бұл жағдайда жақсы ымыра - әртүрлі қолжетімділік аймақтарын таңдау.

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

Тұрақты манифесттер

Kubernetes веб-сайтында бар өте жақсы нұсқаулық манифесттерді пайдаланып ZooKeeper конфигурациялау жолы туралы. ZooKeeper Кафканың бөлігі болғандықтан, бұл жерде Kubernetes тұжырымдамалары қолданылатынымен танысу үшін жақсы орын. Мұны түсінгеннен кейін, Кафка кластерімен бірдей ұғымдарды пайдалануға болады.

• By: Pod - Kubernetes жүйесіндегі ең кіші орналастыруға болатын құрылғы. Қондырғыда сіздің жұмыс жүктемеңіз бар және оның өзі кластердегі процеске сәйкес келеді. Қапшықта бір немесе бірнеше контейнер бар. Ансамбльдегі әрбір ZooKeeper сервері және Кафка кластеріндегі әрбір брокер жеке бөлімшеде жұмыс істейді.
• StatefulSet: StatefulSet - бірнеше күйі бар жұмыс жүктемелерін өңдейтін Kubernetes нысаны және мұндай жұмыс жүктемелері үйлестіруді қажет етеді. StatefulSets подкасттарды ретке келтіруге және олардың бірегейлігіне қатысты кепілдіктер береді.
• Бассыз қызметтер: Қызметтер логикалық атауды пайдаланып клиенттерден подкасттарды ажыратуға мүмкіндік береді. Кубернетес бұл жағдайда жүктемені теңестіруге жауапты. Дегенмен, ZooKeeper және Kafka сияқты күйі бар жұмыс жүктемелерін пайдаланған кезде, клиенттер белгілі бір данаммен байланысуы керек. Дәл осы жерде бассыз қызметтер пайдалы болады: бұл жағдайда клиенттің логикалық аты болады, бірақ сіз подкастпен тікелей байланысудың қажеті жоқ.
• Ұзақ мерзімді сақтау көлемі: Бұл көлемдер жоғарыда аталған жергілікті емес блоктың тұрақты сақтау орнын конфигурациялау үшін қажет.

туралы Йолеан Кубернетестегі Кафкамен жұмысты бастауға көмектесетін манифесттердің толық жинағын ұсынады.

Руль диаграммалары

Helm - yum, apt, Homebrew немесе Chocolatey сияқты ОЖ пакет менеджерлерімен салыстыруға болатын Kubernetes пакетінің менеджері. Ол Helm диаграммаларында сипатталған алдын ала анықталған бағдарламалық пакеттерді орнатуды жеңілдетеді. Жақсы таңдалған Helm диаграммасы Kubernetes жүйесінде Кафканы пайдалану үшін барлық параметрлерді қалай дұрыс конфигурациялау қиын тапсырманы жеңілдетеді. Бірнеше Кафка диаграммасы бар: ресмисі орналасқан инкубатор жағдайында, біреуі бар Тұндырғыш, тағы біреуі - бастап Bitnami.

Операторлар

Helm-де белгілі бір кемшіліктер болғандықтан, тағы бір құрал айтарлықтай танымал болуда: Kubernetes операторлары. Оператор Kubernetes үшін бағдарламалық қамтамасыз ету пакеттерін ғана емес, сондай-ақ осындай бағдарламалық қамтамасыз етуді орналастыруға және оны басқаруға мүмкіндік береді.

тізім таңғажайып операторлар Кафка үшін екі оператор аталды. Олардың біреуі - Стримци. Strimzi көмегімен Кафка кластерін бірнеше минут ішінде іске қосу оңай. Іс жүзінде ешқандай конфигурация қажет емес, сонымен қатар оператордың өзі кейбір жақсы мүмкіндіктерді қамтамасыз етеді, мысалы, кластердегі нүктеден нүктеге TLS шифрлауы. Confluent сонымен қатар қамтамасыз етеді меншікті оператор.

өнімділік

Кафка данасын салыстыру арқылы өнімділікті тексеру маңызды. Мұндай сынақтар проблемалар туындамас бұрын ықтимал кедергілерді табуға көмектеседі. Бақытымызға орай, Кафка екі өнімділікті тексеру құралын ұсынады: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Оларды белсенді түрде пайдаланыңыз. Анықтама үшін бөлімде сипатталған нәтижелерге жүгінуге болады осы пост Джей Крепс немесе назар аударыңыз бұл шолу Amazon MSK Стефан Маарек.

операциялар

Бақылау

Жүйедегі ашықтық өте маңызды - әйтпесе онда не болып жатқанын түсінбейсіз. Бүгінгі таңда бұлттың жергілікті стилінде метрикаға негізделген бақылауды қамтамасыз ететін қатты құралдар жинағы бар. Осы мақсатқа арналған екі танымал құрал - Прометей және Графана. Prometheus JMX экспорттаушысы арқылы барлық Java процестерінен (Kafka, Zookeeper, Kafka Connect) көрсеткіштерді жинай алады - қарапайым түрде. Егер cAdvisor көрсеткіштерін қоссаңыз, Kubernetes жүйесінде ресурстардың қалай пайдаланылатынын толық түсінуге болады.

Стримциде Кафкаға арналған Grafana бақылау тақтасының өте ыңғайлы мысалы бар. Ол негізгі көрсеткіштерді бейнелейді, мысалы, аз репликацияланған секторлар немесе желіден тыс секторлар туралы. Онда бәрі өте анық. Бұл көрсеткіштер ресурстарды пайдалану және өнімділік ақпаратымен, сондай-ақ тұрақтылық көрсеткіштерімен толықтырылады. Осылайша сіз Кафка кластерінің негізгі мониторингін тегін аласыз!

Ақпарат көзі: streamzi.io/docs/master/#kafka_dashboard

Осының бәрін тұтынушы мониторингімен (тұтынушылар мен өндірушілер бойынша көрсеткіштер), сондай-ақ кідіріс мониторингімен (бұл үшін бар) толықтыру жақсы болар еді. Burrow) және түпкілікті бақылау - осы пайдалану үшін Кафка мониторы.

Тіркеу

Тіркеу - тағы бір маңызды міндет. Kafka орнатуыңыздағы барлық контейнерлер жүйеге кіргеніне көз жеткізіңіз stdout и stderr, сонымен қатар Kubernetes кластері барлық журналдарды орталық тіркеу инфрақұрылымына біріктіретініне көз жеткізіңіз, мысалы: Elasticearch.

Функционалды тестілеу

Kubernetes подкасттардың қалыпты жұмыс істеп тұрғанын тексеру үшін белсенділік пен дайындық зондтарын пайдаланады. Егер белсенділікті тексеру сәтсіз болса, Kubernetes сол контейнерді тоқтатады, содан кейін қайта іске қосу саясаты сәйкес орнатылған болса, оны автоматты түрде қайта іске қосады. Дайындықты тексеру сәтсіз болса, Kubernetes подкастты қызмет көрсету сұрауларынан оқшаулайды. Осылайша, мұндай жағдайларда қолмен араласу бұдан былай мүлдем қажет емес, бұл үлкен плюс.

Жаңартуларды шығару

StatefulSets автоматты жаңартуларды қолдайды: RollingUpdate стратегиясын таңдасаңыз, Кафка астындағы әрқайсысы кезекпен жаңартылады. Осылайша тоқтау уақытын нөлге дейін азайтуға болады.

Масштабтау

Кафка кластерін масштабтау оңай жұмыс емес. Дегенмен, Кубернетес репликалардың белгілі бір санына дейін подкасттарды масштабтауды өте жеңілдетеді, яғни сіз Кафка брокерлерін қалағаныңызша декларативті түрде анықтай аласыз. Бұл жағдайда ең қиын нәрсе масштабтаудан кейін немесе кішірейту алдында секторларды қайта тағайындау болып табылады. Тағы да Кубернетес сізге бұл тапсырманы орындауға көмектеседі.

басқарма

Тақырыптарды жасау және секторларды қайта тағайындау сияқты Кафка кластерін басқаруға қатысты тапсырмаларды тармақтардағы пәрмен жолы интерфейсін ашу арқылы бар қабық сценарийлерін пайдалану арқылы орындауға болады. Дегенмен, бұл шешім өте әдемі емес. Strimzi басқа оператор арқылы тақырыптарды басқаруды қолдайды. Мұнда жақсартуға мүмкіндік бар.

Сақтық көшірме жасау және қалпына келтіру

Енді Кафканың қол жетімділігі Кубернетестің қол жетімділігіне де байланысты болады. Егер сіздің Kubernetes кластері сәтсіз болса, ең нашар сценарийде Кафка кластері де сәтсіздікке ұшырайды. Мерфи заңына сәйкес, бұл міндетті түрде болады және сіз деректерді жоғалтасыз. Тәуекелдің бұл түрін азайту үшін жақсы сақтық көшірме тұжырымдамасына ие болыңыз. MirrorMaker қолданбасын пайдалануға болады, басқа опция осында сипатталғандай бұл үшін S3 пайдалану болып табылады пошта Заландодан.

қорытынды

Шағын және орташа өлшемді Кафка кластерлерімен жұмыс істегенде, Kubernetes-ті қолданған жөн, өйткені ол қосымша икемділікті қамтамасыз етеді және оператор тәжірибесін жеңілдетеді. Егер сізде өте маңызды жұмыс істемейтін кідіріс және/немесе өткізу қабілеті талаптары болса, басқа орналастыру опциясын қарастырған дұрыс.

Ақпарат көзі: www.habr.com