Kafka на Kubernetes - гэта добра?

Вітаем вас, Хабр!

У свой час мы першымі вывелі на расейскі рынак тэму Кафка і працягваем сачыць за яе развіццём. У прыватнасці, нам падалася цікавай тэма ўзаемадзеяння Kafka і Kubernetes. Аглядная (і даволі асцярожная) артыкул на гэтую тэму выходзіла ў блогу кампаніі Confluent яшчэ ў кастрычніку мінулага гады пад аўтарствам Гвен Шапіры. Сёння ж мы хочам звярнуць вашу ўвагу на больш свежы, красавіцкі артыкул Ёхана Гайгера (Johann Gyger), які, хоць і не абышоўся без пытальніка ў назве, разглядае тэму ў больш прадметным ключы, суправаджаючы тэкст цікавымі спасылкамі. Прабачце нам, калі ласка, вольны пераклад «chaos monkey», калі зможаце!

Увядзенне

Kubernetes прызначаны для працы з нагрузкамі, якія не захоўваюць стан. Як правіла, такія працоўныя нагрузкі прадстаўлены ў форме мікрасэрвіснай архітэктуры, яны легкаважныя, добра паддаюцца гарызантальнаму маштабаванню, падпарадкоўваюцца прынцыпам 12-фактарных прыкладанняў, дазваляюць працаваць з аўтаматычнымі выключальнікамі (circuit breaker) і малпамі-ламачкамі (chaos monkeys).

Kafka, размешчаны з іншага боку, у сутнасці, выступае ў ролі размеркаванай базы дадзеных. Такім чынам, пры працы вам даводзіцца мець справу са станам, а яно значна цяжкавагавыя мікрасэрвісу. Kubernetes падтрымлівае нагрузкі з захаваннем стану, але, як паказвае Келсі Хайтауэр у двух сваіх твітах, з імі варта абыходзіцца асцярожна:

Некаторым здаецца, што, калі накаціць Kubernetes на нагрузку з захаваннем стану, ён ператвараецца ў цалкам кіраваную базу дадзеных, здольную супернічаць з RDS. Гэта не так. Можа быць, калі дастаткова папрацаваць, прыкруціць дадатковыя кампаненты і прыцягнуць каманду SRE-інжынераў, то атрымаецца ўладкаваць RDS па-над Kubernetes.

Заўсёды ўсім рэкамендую выяўляць выключную асцярожнасць, запускаючы нагрузкі з захаваннем стану на Kubernetes. Большасць з тых, хто цікавіцца, ці змагу я запускаць на Kubernetes нагрузкі з захаваннем стану не валодаюць дастатковым досведам у працы з Kubernetes, а часцяком і з той нагрузкай, пра якую пытаюцца.

Такім чынам, ці варта запускаць Kafka на Kubernetes? Сустрэчнае пытанне: а ці будзе Kafka лепш працаваць без Kubernetes? Вось чаму я хачу падкрэсліць у гэтым артыкуле, як Kafka і Kubernetes дапаўняюць адзін аднаго, і якія падводныя камяні могуць трапіцца пры іх спалучэнні.

Час выканання

Давайце пагаворым аб базавай рэчы - асяроддзі часу выканання як такой

працэс

Брокеры Kafka зручныя пры працы з CPU. TLS можа прынесці некаторыя выдаткі. Пры гэтым, кліенты Kafka могуць мацней нагружаць CPU, калі выкарыстоўваюць шыфраванне, але гэта не ўплывае на брокераў.

памяць

Брокеры Kafka аджыраюць памяць. Памер кучы JVM звычайна модна абмежаваць 4-5 Гб, але вам таксама спатрэбіцца шмат сістэмнай памяці, паколькі Kafka вельмі актыўна выкарыстоўвае старонкавы кэш. У Kubernetes якая адпавядае выявай задавайце межы кантэйнера на рэсурсы і запыты.

Сховішча дадзеных

Сховішча дадзеных у кантэйнерах з'яўляецца эфемерным - дадзеныя губляюцца пры перазапуску. Для дадзеных Kafka можна выкарыстоўваць том emptyDir, і эфект будзе аналагічным: дадзеныя вашага брокера будуць страчаны пасля завяршэння. Вашы паведамленні ўсё роўна могуць захавацца на іншых брокерах у якасці рэплік. Таму, пасля перазапуску які адмовіў брокер павінен перш за ўсё рэплікаваць усе дадзеныя, а на гэты працэс можа спатрэбіцца нямала часу.

Вось чаму варта выкарыстоўваць доўгачасовае сховішча дадзеных. Няхай гэта будзе нелакальнае доўгачасовае сховішча з файлавай сістэмай XFS ці, дакладней, ext4. Не выкарыстоўвайце NFS. Я папярэдзіў. NFS версій v3 ці v4 працаваць не будзе. Карацей кажучы, брокер Kafka завершыцца, калі не зможа выдаліць каталог з дадзенымі з-за праблемы з "дурнымі перайменаваннямі", актуальнай у NFS. Калі я вас да гэтага часу не пераканаў, вельмі ўважліва прачытайце гэты артыкул. Сховішча дадзеных павінна быць нелакальным, каб Kubernetes мог больш гнутка выбіраць новы вузел пасля перазапуску ці рэлакацыі.

сетка

Як і ў выпадку з большасцю размеркаваных сістэм, прадукцыйнасць Kafka вельмі моцна залежыць ад таго, каб затрымкі ў сетцы былі мінімальнымі, а шырыня паласы – максімальнай. Не спрабуйце размясціць усе брокеры на адным і тым жа вузле, бо ў выніку паменшыцца даступнасць. Калі адмовіць вузел Kubernetes, тое адмовіць і ўвесь кластар Kafka. Таксама не разгрупоўвайце кластар Kafka па цэлым датацэнтрам. Тое ж датычыцца кластара Kubernetes. Добры кампраміс у дадзеным выпадку - абраць розныя зоны даступнасці.

Канфігурацыя

Звычайныя маніфесты

На сайце Kubernetes ёсць вельмі добрае кіраўніцтва аб тым, як наладзіць ZooKeeper пры дапамозе маніфестаў. Паколькі ZooKeeper уваходзіць у склад Kafka, менавіта з гэтага зручна пачынаць знаёміцца ​​з тым, якія канцэпцыі Kubernetes тут дастасавальныя. Разабраўшыся з гэтым, вы зможаце задзейнічаць тыя ж канцэпцыі і з кластарам Kafka.

• Пад: пад - гэта мінімальная разгортваецца адзінка ў Kubernetes. У подзе змяшчаецца ваша працоўная нагрузка, а сам пад адпавядае працэсу ў вас у кластары. У подзе змяшчаецца адзін або больш кантэйнераў. Кожны сервер ZooKeeper у ансамблі і кожны брокер у кластары Kafka будуць працаваць у асобным подзе.
• StatefulSet: StatefulSet - гэта аб'ект Kubernetes, які працуе са множнымі працоўнымі нагрузкамі, якія захоўваюць станамі, а такія нагрузкі патрабуюць каардынацыі. StatefulSet даюць гарантыі адносна ўпарадкавання подаў і іх унікальнасці.
• Headless-сэрвісы: Сэрвісы дазваляюць адмацоўваць поды ад кліентаў пры дапамозе лагічнага імя. Kubernetes у дадзеным выпадку адказвае за балансаванне нагрузкі. Аднак, пры аперацыях з працоўнымі нагрузкамі, якія захоўваюць стан, як у выпадку з ZooKeeper і Kafka, кліентам неабходна абменьвацца інфармацыяй з канкрэтным інстансам. Менавіта тут вам і спатрэбяцца headless-сэрвісы: у такім разе ў кліента ўсё роўна будзе лагічнае імя, але напроста да поду можна будзе не звяртацца.
• Тым для доўгачасовага захоўвання: такія тамы патрэбныя для канфігурацыі нелакальнага блокавага доўгачасовага сховішча, якое згадвалася вышэй.

На Yolean падаецца вычарпальны набор маніфестаў, пры дапамозе якіх зручна пачаць працу з Kafka на Kubernetes.

Helm-дыяграмы

Helm - гэта мэнэджар пакетаў для Kubernetes, які можна параўнаць з мэнэджэрамі пакетаў для АС, такімі як yum, apt, Homebrew або Chocolatey. З яго дапамогай зручна ўсталёўваць загадзя вызначаныя праграмныя пакеты, апісаныя ў дыяграмах Helm. Добра падабраная дыяграма Helm палягчае складаную задачу: як правільна сканфігураваць усе параметры для выкарыстання Kafka на Kubernetes. Ёсць некалькі дыяграм Kafka: афіцыйная знаходзіцца у інкубатарным стане, ёсць адна ад Пераход, яшчэ адна - ад Bitnami.

Аператары

Паколькі Helm ўласцівы пэўныя недахопы, немалую папулярнасць набывае яшчэ адзін сродак: аператары Kubernetes. Аператар не проста пакуе софт для Kubernetes, але і дазваляе вам разгортваць такі софт, а таксама кіраваць ім.

У спісе узрушаючых аператараў згадваюцца два аператары для Kafka. Адзін з іх - Strimzi. Пры дапамозе Strimzi не складае ніякай цяжкасці падняць кластар Kafka за лічаныя хвіліны. Практычна ніякай канфігурацыі ўносіць не патрабуецца, акрамя таго, сам аператар падае сякія-такія прыемныя магчымасці, напрыклад, шыфраванне TLS выгляду "кропка-кропка" усярэдзіне кластара. Confluent таксама дае уласны аператар.

Proizvoditelnost

Вельмі важна тэставаць прадукцыйнасць, забяспечваючы ўсталяваны ў вас асобнік Kafka кантрольнымі кропкамі. Такія тэсты дапамогуць вам выявіць патэнцыйныя вузкія месцы, пакуль не пачаліся праблемы. Да шчасця, у Kafka ужо падаецца два прылады для тэставання прадукцыйнасці: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Актыўна карыстайцеся імі. Для даведкі можаце спраўджвацца з вынікамі, апісанымі ў гэтым пасце Джэем Крэпсам, альбо арыентавацца на гэты агляд Amazon MSK ад Stéphane Maarek.

аперацыі

Маніторынг

Празрыстасць у сістэме вельмі важная - інакш вы не зразумееце, што ў ёй адбываецца. Сёння маецца самавіты інструментар, які забяспечвае маніторынг на аснове метрык у стылі cloud native. Два папулярных інструмента для гэтай мэты - Prometheus і Grafana. Prometheus можа збіраць метрыкі з усіх працэсаў Java (Kafka, Zookeeper, Kafka Connect) пры дапамозе экспарцёра JMX - самай простай выявай. Калі дадаць метрыкі cAdvisor, то можна будзе больш поўна ўяўляць, як у Kubernetes выкарыстоўваюцца рэсурсы.

У Strimzi ёсць вельмі зручны прыклад дашборда Grafana для Kafka. Ён візуалізуе ключавыя метрыкі, напрыклад, аб недарэплікаваных сектарах або аб тых, што знаходзяцца афлайн. Тамака ўсё вельмі зразумела. Гэтыя метрыкі дапаўняюцца звесткамі аб выкарыстанні рэсурсаў і прадукцыйнасці, а таксама індыкатарамі стабільнасці. Такім чынам, вы атрымліваеце базавы маніторынг кластара Kafka за проста так!

Крыніца: strimzi.io/docs/master/#kafka_dashboard

Усё гэта нядрэнна было б дапоўніць маніторынгам кліентаў (метрыкі па кансьюмерах і прад'юсерам), а таксама маніторынгам запазнення (для гэтага ёсць нара) і скразным маніторынгам – для гэтага выкарыстоўвайце Kafka Monitor.

Лагіраванне

Лагіраванне - яшчэ адна найважнейшая задача. Пераканайцеся, што ўсе кантэйнеры ў вашай ўстаноўцы Kafka лагуюцца ў stdout и stderr, а таксама паклапаціцеся аб тым, каб ваш кластар Kubernetes агрэгаваў усе логі ў цэнтральнай часопіснай інфраструктуры, напрыклад, у Elasticsearch.

праверка працаздольнасці

Kubernetes выкарыстоўвае зонды "жывасці" (liveness) і гатоўнасці (readiness) каб праверыць, ці нармальна працуюць вашы поды. Калі праверка на жвавасць не ўдаецца, Kubernetes спыніць гэты кантэйнер, а затым аўтаматычна перазапусціць яго, калі палітыка перазапуску ўстаноўлена адпаведным чынам. Калі не ўдаецца праверка на гатоўнасць, то Kubernetes ізалюе гэты пад ад абслугоўвання запытаў. Такім чынам, у падобных выпадках больш увогуле не патрабуецца ўмяшання ўручную, а гэта вялікі плюс.

Выкочванне абнаўленняў

StatefulSet падтрымліваюць аўтаматычныя абнаўленні: пры выбары стратэгіі RollingUpdate кожны пад Kafka будзе абнаўляцца па чарзе. Такім чынам можна звесці працягласць прастояў да нуля.

маштабаванне

Маштабаванне кластара Kafka - няпростая задача. Аднак, у Kubernetes вельмі проста маштабаваць поды да пэўнай колькасці рэплік, а гэта значыць, што вы зможаце дэкларатыўна вызначыць столькі брокераў Kafka, колькі захочаце. Самае складанае ў дадзеным выпадку - перапрысвойванне сектараў пасля маштабавання ўверх або перад маштабаваннем ўніз. Ізноў жа, з гэтай задачай вам дапаможа Kubernetes.

адміністраванне

Задачы, звязаныя з адміністраваннем вашага кластара Kafka, у прыватнасці, стварэнне топікаў і перапрысвойванне сектараў можна зрабіць пры дапамозе наяўных шелл-скрыптоў, адчыняючы інтэрфейс каманднага радка ў вашых падах. Аднак такое рашэнне не занадта прыгожае. Strimzi падтрымлівае кіраванне топікі пры дапамозе іншага аператара. Тут ёсьць што дапрацоўваць.

Рэзервовае копіраванне і аднаўленне

Цяпер даступнасць Kafka у нас будзе залежаць і ад даступнасці Kubernetes. Калі ў вас упадзе кластар Kubernetes, то ў горшым выпадку ўпадзе і кластар Kafka. Па законе Мерфі гэта абавязкова адбудзецца, і вы страціце дадзеныя. Каб зменшыць рызыку такога роду, добра прапрацуйце канцэпцыю рэзервовага капіявання. Можна скарыстацца MirrorMaker, іншы варыянт - задзейнічаць для гэтага S3, як апісана ў гэтым пасце ад Zalando.

Заключэнне

Пры працы з невялікімі ці сярэднімі кластарамі Kafka вызначана мэтазгодна выкарыстоўваць Kubernetes, паколькі ён забяспечвае дадатковую гнуткасць і спрашчае працу з аператарамі. Калі перад вамі стаяць вельмі сур'ёзныя нефункцыянальныя патрабаванні, датычныя затрымкі і/ці прапускной здольнасці, то, магчыма, лепш разгледзець які-небудзь іншы варыянт разгортвання.

Крыніца: habr.com