Kafka на Kubernetes це добре?

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

Свого часу ми першими вивели на російський ринок тему Кафка і продовжуємо стежити за її розвитком. Зокрема, нам здалася цікавою тема взаємодії Kafka та Кубернетес. Оглядова (і досить обережна) стаття на цю тему виходила у блозі компанії 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 не важко підняти кластер 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

Все це непогано було б доповнити моніторингом клієнтів (метрики з консьюмерів та прод'юсерів), а також моніторингом запізнення (для цього є Нора) та наскрізним моніторингом – для цього використовуйте 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