Недавно мы рассказывали про KubeMQ – stateless-сервис обмена сообщениями для Kubernetes, который может заменить собой сложное развертывание Apache Kafka на этой платформе управления контейнерами. Сегодня разберем, как устроен KubeMQ и сравним его с Apache Kafka по нескольким параметрам, наиболее интересным для разработчиков распределенных приложений и администраторов.
Операторы и пользовательские ресурсы в Kubernetes
Одной из важнейших частей экосистемы Kubernetes являются операторы, впервые представленные CoreOS в 2016 году для использования API этой платформы контейнерной виртуализации для развертывания и управления состоянием приложений в различных средах. Они поддерживают состояние в рамках федеративного развертывания Kubernetes, когда несколько кластеров работают вместе и между отдельными кластерами.
На высоком уровне операторы позволяют автоматизировать задачи, выходящие за рамки того, что изначально предоставляет Kubernetes. Операторы — это программные расширения, которые подключаются к Kubernetes API и плоскости управления для управления пользовательским ресурсом (CR, Custom Resource). Напомним, ресурс – это конечная точка в Kubernetes API, которая хранит коллекцию объектов API определенного типа, например, встроенный ресурс pods содержит коллекцию подов – объектов типа Pod.
Пользовательский ресурс — это расширение Kubernetes API, которое может отсутствовать в стандартной установке K8s и является настройкой отдельной установки. Сегодня многие основные функции Kubernetes создаются с использованием пользовательских ресурсов, чтобы платформа была более модульной. Пользовательские ресурсы могут появляться и исчезать в работающем кластере посредством динамической регистрации, а администраторы кластера могут обновлять их независимо от самого кластера. После установки CR пользователи могут создавать и получать доступ к его объектам с помощью kubectl, аналогично тому, как это делается для встроенных ресурсов типа Pod.
По сути, CR описывает желаемое состояние приложения, а сам оператор как инструмент управления контролирует его, чтобы гарантировать корректную работу приложения. Например, оператор может развертывать и масштабировать под, создавать и восстанавливать резервную копию, управлять сетевыми службами и входящими данными или управлять постоянным хранилищем данных.
Поскольку операторы подключаются к встроенным инструментам Kubernetes, таким как kubectl, они стали общим языком для управления сложными развертываниями с состоянием. Популярный менеджер пакетов Helm отлично подходит для развертывания и управления stateless-приложениями, такими как веб-серверы. А для развертывания stateful-систем типа etcd, PostgreSQL и KubeMQ, необходимы операторы. Но, прежде чем погрузиться, почему операторы так важны для KubeMQ, сначала рассмотрим преимущества этой платформы обмена сообщениями над Apache Kafka.
KubeMQ vs Apache Kafka на Kubernetes
Развертывание Apache Kafka на Kubernetes – не самая простая задача, о чем мы писали здесь, здесь и здесь. Заменить сложную комбинацию этих двух технологий, чтобы обеспечить обмен сообщениями между контейнерными приложениями, поможет KubeMQ – брокер и очередь обмена сообщениями специально для Kubernetes. KubeMQ не имеет состояния, т.е. каждый его узел остается неизменным, предсказуемым и воспроизводимым на протяжении всего жизненного цикла системы. Изначально KubeMQ поставляется с нулевой конфигурацией и, в отличие от Kafka, не требует сложной настройки параметров после установки. KubeMQ поддерживает все шаблоны обмена сообщениями, что и Kafka, а также имеет коннекторы приемника и источника для преобразования сообщений из топиков этой распределенной платформы потоковой передачи событий.
Сравним Kafka и KubeMQ по следующим параметрам:
- развертывание на Kubernetes. KubeMQ по умолчанию поставляется в предварительно настроенном кластере для Kubernetes. Поэтому развертывание полностью работоспособного кластера в производственной среде происходит очень просто и быстро, занимая около пяти минут. KubeMQ предлагает мастер установки, который генерирует готовый к развертыванию YAML или HELM. Для локальной установки перед развертыванием кластера можно попробовать Docker-образ KubeMQ. Миграция из среды разработки в production также происходит прозрачно без дополнительных настроек или изменений кода, что экономит время и сводит к минимуму ошибки. В случае Apache Kafka развертывание платформы сложно само по себе, а на Kubernetes становится еще сложнее, т.к. она изначально не создавалась под специфику этой среды управления контейнерами
- размер кластера. KubeMQ представляет собой легкий и компактный контейнер размером около 30 МБ, что отлично подходит для микросервисной архитектуры. При этом не требуется устанавливать дополнительные компоненты типа Zookeeper как в Kafka, отказаться от которого в production пока еще не рекомендуется, несмотря на наличие внутреннего Quorum Controller с протоколом KRaft в версии 2.8.Каждый контейнер Kafka весит около 600 МБ (в 20 раз больше, чем контейнер KubeMQ), а каждый контейнер Zookeeper весит около 100 МБ. Таким образом, 3 контейнера Kafka и Zookeeper в сумме будут весить 2,1 ГБ, тогда как 3 контейнера KubeMQ – всего 90 МБ.
- Скорость. KubeMQ был написан на языке системного программирования Go для максимального использования аппаратных ресурсов и бесперебойной работы с Kubernetes. Бенчмаркинговые тесты по отправке миллиона сообщений размером 1 Кб на одном и том же оборудовании показали, что KubeMQ оказался на 20% быстрее Kafka.
- Простота использования. KubeMQ изначально создан так, чтобы повысить скорость и производительность разработчиков, DevOps-инженеров и администраторов. Он не требует огромного объема знаний о группах, брокерах и прочих дополнительных настройках, так как все это делается в KubeMQ автоматически. А благодаря Raft-протоколу KubeMQ не нужен внешний сервис синхронизации метаданных Zook Что касается администрирования и эксплуатации Apache Kafka, здесь не обойтись без специализированных курсов и обучения тонкостям этой платформы. Разработчику необходимо знание Java или Scala, а администратору кластера следует заранее знать о его конфигурации. Кроме того, пока Zookeeper не полностью исключен из Kafka, его настройка и обслуживание также требуют времени и сил.
- Шаблоны обмена сообщениями. Будучи одновременно и брокером, и очередью сообщений, KubeMQ поддерживает как синхронные, так и асинхронные шаблоны, в т.ч. Pub/Sub, запрос/ответ, потоковую передачу и RPC. Kafka работает только с асинхронными шаблонами и не поддерживает RPC.
- интеграция с собственными облачными технологиями. Поскольку KubeMQ изначально разработан для Kubernetes, он включает готовые интеграции с ведущими проектами CNCF (Cloud Native Computing Foundation), например, Prometheus, Grafana, Fluentd, Elastics, Jaeger, Open Tracing. Также доступны дополнительные интеграции с DataDog, Loggly, AWS, Honeycomb, Stackdriver и Zipkin и есть возможность подключать дополнительные инструменты с помощью системы плагинов KubeMQ. Apache Kafka не является встроенным элементом CNCF-ландшафта, и каждая интеграция должна настраиваться отдельно.
Как устроен KubeMQ и при чем здесь операторы K8s
KubeMQ состоит из четырех основных компонентов:
- сервер обработки сообщений, который развертывается в каждом кластере Kubernetes;
- мосты, которые помогают построить желаемую топологию обмена сообщениями между кластерами, отправляя сообщения между серверами KubeMQ;
- источники, которые принимают сообщения из существующих систем, включая RabbitMQ или Kafka, и отправляют их в KubeMQ;
- цели, которые отправляют сообщения во внешние системы (СУБД, файловые или объектные хранилища, другие системы обмена сообщениями).
Объединение всех этих компонентов позволяет создать в Kubernetes архитектуру межкластерного обмена сообщениями и микросервисов без разработки дополнительного кода благодаря использованию операторов. Сам KubeMQ развертывается в качестве оператора, гарантируя работу на уровне Kubernetes. А благодаря принципу объединения множества небольших кластеров вместо одного массивного, KubeMQ обеспечивает высокую производительность, масштабируемость и отказоустойчивость
Оператор развертывает кластеры и обеспечивает правильную настройку различных мостов, источников и целей KubeMQ для каждого кластера, позволяя подключить его к собственным моделям данных, событиям и API Kubernetes. Это упрощает управление состоянием кластера и проверку конфигурации, а также сокращает накладные расходы благодаря эластичному масштабированию инфраструктуры в зависимости от нагрузки.
Оператор KubeMQ также помогает отслеживать состояния, что особенно актуально для гибридных облачных развертываний. Это может подтвердить наличие желаемой емкости и конфигурации для каждого кластера. Сравнение желаемого состояния в CR с существующим состоянием в Kubernetes позволяет оператору гарантировать выявление и устранение сбоев, а также увеличение емкости по мере необходимости и настройки компонентов KubeMQ.
В заключение еще раз отметим, что KubeMQ отлично интегрирован с Apache Kafka, а потому их можно использовать совместно в постоянном режиме или на период перехода от развертывания Kafka на Kubernetes. Также вместо KubeMQ для развертывания Kafka на Kubernetes можно использовать Strimzi, о котором мы рассказываем здесь.
Больше подробностей про администрирование и эксплуатацию Apache Kafka для потоковой аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков больших данных в Москве:
Источники
