Добър ли е Kafka на Kubernetes?

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

По едно време ние бяхме първите, които представиха темата на руския пазар Кафка и продължете писта за неговото развитие. По-специално открихме темата за взаимодействието между Кафка и Kubernetes. Наблюдаемо (и доста внимателно) статия тази тема беше публикувана в блога Confluent през октомври миналата година под авторството на Гуен Шапира. Днес бихме искали да насочим вниманието ви към една по-нова статия от април на Йохан Гигер, която, макар и не без въпросителна в заглавието, разглежда темата по-съдържателно, придружавайки текста с интересни връзки. Моля, простете ни безплатния превод на „хаос маймуна“, ако можете!

въведение

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

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

Някои хора смятат, че ако включите Kubernetes в работно натоварване със състояние, тя се превръща в напълно управлявана база данни, която съперничи на RDS. Това е грешно. Може би, ако работите достатъчно усилено, добавите допълнителни компоненти и привлечете екип от SRE инженери, ще можете да изградите RDS върху Kubernetes.

Винаги препоръчвам на всеки да бъде изключително внимателен, когато изпълнява работни натоварвания със състояние на Kubernetes. Повечето хора, които питат „мога ли да стартирам работни натоварвания със състояние на Kubernetes“, нямат достатъчно опит с Kubernetes и често с работното натоварване, за което питат.

И така, трябва ли да стартирате Kafka на Kubernetes? Контравъпрос: ще работи ли Kafka по-добре без Kubernetes? Ето защо искам да подчертая в тази статия как Kafka и Kubernetes се допълват взаимно и какви капани могат да дойдат при комбинирането им.

Време на завършване

Нека поговорим за основното - самата среда за изпълнение

процес

Брокерите на Kafka са удобни за процесора. TLS може да доведе до допълнителни разходи. Клиентите на Kafka обаче може да са по-интензивни на процесора, ако използват криптиране, но това не засяга брокерите.

Память

Брокерите на Кафка изяждат паметта. Размерът на купчината на JVM обикновено е ограничен до 4-5 GB, но ще ви трябва и много системна памет, тъй като 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, който обработва множество натоварвания със състояние и такива натоварвания изискват координация. StatefulSets предоставят гаранции по отношение на подреждането на подовете и тяхната уникалност.
• Безглави услуги: Услугите ви позволяват да отделяте подове от клиенти с помощта на логично име. Kubernetes в този случай отговаря за балансирането на натоварването. Въпреки това, когато работят с работни натоварвания със състояние, като ZooKeeper и Kafka, клиентите трябва да комуникират с конкретен екземпляр. Това е мястото, където услугите без глава са полезни: в този случай клиентът все още ще има логично име, но няма да се налага да се свързвате директно с pod.
• Обем за дългосрочно съхранение: Тези томове са необходими за конфигуриране на нелокалното блоково постоянно съхранение, споменато по-горе.

На Йолиан Предоставя изчерпателен набор от манифести, за да ви помогне да започнете с Kafka в Kubernetes.

Хелм диаграми

Helm е пакетен мениджър за Kubernetes, който може да се сравни с операционни пакетни мениджъри като yum, apt, Homebrew или Chocolatey. Улеснява инсталирането на предварително дефинирани софтуерни пакети, описани в диаграмите на Helm. Една добре подбрана диаграма на Helm прави лесна трудната задача как правилно да конфигурирате всички параметри, за да използвате Kafka на Kubernetes. Има няколко диаграми на Кафка: официалната се намира в състояние на инкубатор, има един от кръстовище, още един - от Bitnami.

оператори

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

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

продуктивност

Важно е да тествате производителността чрез сравняване на вашия екземпляр на Kafka. Такива тестове ще ви помогнат да откриете потенциални тесни места, преди да възникнат проблеми. За щастие Kafka вече предоставя два инструмента за тестване на производителността: kafka-producer-perf-test.sh и kafka-consumer-perf-test.sh. Използвайте ги активно. За справка можете да се обърнете към резултатите, описани в тази публикация Джей Крепс, или се съсредоточете върху този преглед Amazon MSK от Stéphane Maarek.

операции

мониторинг

Прозрачността в системата е много важна - иначе няма да разберете какво се случва в нея. Днес има солиден инструментариум, който осигурява мониторинг, базиран на показатели, в естествен стил на облака. Два популярни инструмента за тази цел са Prometheus и Grafana. Prometheus може да събира показатели от всички Java процеси (Kafka, Zookeeper, Kafka Connect) с помощта на JMX експортер - по най-простия начин. Ако добавите показатели на cAdvisor, можете да разберете по-добре как се използват ресурсите в Kubernetes.

Strimzi има много удобен пример за табло за управление на Grafana за Kafka. Той визуализира ключови показатели, например за недостатъчно репликирани сектори или такива, които са офлайн. Там всичко е много ясно. Тези показатели се допълват от информация за използването на ресурсите и ефективността, както и от индикатори за стабилност. Така че получавате основно наблюдение на клъстери на Kafka за нищо!

Източник: streamzi.io/docs/master/#kafka_dashboard

Би било хубаво всичко това да се допълни с мониторинг на клиенти (метрики за потребители и производители), както и мониторинг на латентност (за това има ровя) и наблюдение от край до край - за тази употреба Кафка монитор.

Сеч

Регистрирането е друга критична задача. Уверете се, че всички контейнери във вашата инсталация на Kafka са регистрирани stdout и stderr, и също така се уверете, че вашият клъстер Kubernetes събира всички регистрационни файлове в централна инфраструктура за регистриране, напр. Elasticsearch.

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

Kubernetes използва сонди за жизненост и готовност, за да провери дали вашите модули работят нормално. Ако проверката на жизнеспособността е неуспешна, Kubernetes ще спре този контейнер и след това автоматично ще го рестартира, ако политиката за рестартиране е зададена съответно. Ако проверката на готовност е неуспешна, Kubernetes изолира групата от заявки за обслужване. Така в такива случаи вече изобщо не е необходима ръчна намеса, което е голям плюс.

Пускане на актуализации

StatefulSets поддържат автоматични актуализации: ако изберете стратегията RollingUpdate, всеки под Kafka ще се актуализира на свой ред. По този начин времето за престой може да бъде намалено до нула.

мащабиране

Мащабирането на клъстер Kafka не е лесна задача. Kubernetes обаче прави много лесно мащабирането на подове до определен брой реплики, което означава, че можете декларативно да дефинирате колкото искате брокери на Kafka. Най-трудното нещо в този случай е преназначаването на сектори след увеличаване или преди намаляване. Отново Kubernetes ще ви помогне с тази задача.

администрация

Задачи, свързани с администрирането на вашия клъстер Kafka, като създаване на теми и преназначаване на сектори, могат да се извършват с помощта на съществуващи скриптове на обвивката чрез отваряне на интерфейса на командния ред във вашите подове. Това решение обаче не е много красиво. Strimzi поддържа управление на теми с помощта на различен оператор. Тук има място за подобрение.

Архивиране и възстановяване

Сега наличието на Kafka също ще зависи от наличието на Kubernetes. Ако вашият клъстер Kubernetes се повреди, тогава в най-лошия случай вашият клъстер Kafka също ще се повреди. Според закона на Мърфи това определено ще се случи и вие ще загубите данни. За да намалите този вид риск, имайте добра резервна концепция. Можете да използвате MirrorMaker, друга опция е да използвате S3 за това, както е описано в това пост от Заландо.

Заключение

Когато работите с малки до средни по размер Kafka клъстери, определено си струва да използвате Kubernetes, тъй като осигурява допълнителна гъвкавост и опростява изживяването на оператора. Ако имате много значителна нефункционална латентност и/или изисквания за пропускателна способност, тогава може би е по-добре да обмислите друга опция за внедряване.

Източник: www.habr.com