Kafka на Kubernetes — това добре ли е?

Добре дошли, Хабър!

В свое време ние за пръв път предложихме тема на руския пазар Kafka и продължаваме да следите да следим развитието. Конкретно, ни заинтересува темата за взаимодействието между Kafka и Kubernetes. Прегледна (и доста предпазлива) статия на тази тема излезе в блога на компанията Confluent още през октомври миналата година с автор Gwen Shapiro. Днес бихме искали да ви обърнем внимание на по-новата статия на Johann Gyger от април, който, макар и да не е избегнал въпросителната в заглавието, разглежда темата в по-конкретен контекст, придружена с интересни линкове. Моля, извинете ни за свободния превод на "chaos monkey", ако можете!

Въведение

Kubernetes е предназначен да работи с натоварвания, които не запазват състояние. Обикновено, такива работни натоварвания се представят под формата на микросервизна архитектура, те са леки, добре подлежащи на хоризонтално мащабиране, спазват принципите на 12-факторни приложения, позволяват работа с автоматични прекъсватели (circuit breaker) и chaos monkeys.

Kafka, от своя страна, всъщност играе ролята на разпределена база данни. Следователно, при работа с нея вие се сблъсквате със състояние, което е много по-тежко от микросервиз. Kubernetes поддържа натоварвания с запазване на състояние, но, както посочва Kelsey Hightower в два свои туита, с тях трябва да се подхожда внимателно:

Някои смятат, че ако сложат 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 диаграми: официалната е в инкубаторно състояние, една е от Confluent, друга – от Bitnami.

Оператори

Тъй като Helm има определени недостатъци, значителна популярност придобива и едно друго средство: операторите на Kubernetes. Операторът не само упакова софтуера за Kubernetes, но също така ви позволява да разгръщате такъв софтуер и да го управлявате.

В списъка на невероятни оператори се споменават двама оператори за Kafka. Единият от тях е Strimzi. С помощта на Strimzi е лесно да настроите Kafka клъстер за минути. Практически не се изисква конфигурация, освен това, самият оператор предлага някои удобни функции, като TLS шифроване от тип „точка до точка“ в рамките на клъстера. Confluent също предлага собствен оператор.

Производителност

Изключително важно е да тествате производителността, снабдявайки инсталирания от вас экземпляр на 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

Всичко това би било добре да бъде допълнено с мониторинг на клиентите (метрики за консумиращите и производителите), както и мониторинг на забавяне (за което има Burrow) и мониторинг на целия поток – за това използвайте Kafka Monitor.

Логиране

Логването е още една основна задача. Убедете се, че всички контейнери във вашата Kafka инсталация се логват в stdout и stderr, а също така се погрижете вашият Kubernetes клъстер да агрегирант всички логове в централна лог инfrastrukturа, например в 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