Какие задачи решают инженеры и администраторы кластера для организации многопользовательского доступа к платформе потоковой передачи событий, а также чем полезен фреймворк Strimzi для развертывания и сопровождения мультиарендной среды Apache Kafka на Kubernetes.
Задачи управления мультипользовательским кластером Kafka
Выступая в качестве средства интеграции информационных систем и микросервисов, в корпоративной среде Apache Kafka является платформенным решением, которое обычно администрируется и управляется выделенной командой инженеров. Хотя за разработку и сопровождение отдельного сервиса отвечает своя команда разработки, инженеры платформенных решений должны обеспечить работоспособность общей ИТ-инфраструктуры. Причем сделать это надо так, чтобы она удовлетворяла требованиям каждого направления, не выходя за рамки общекорпоративных ограничений, таких как бюджет и пр. Для этого инженеры многопользовательского (мультиарендного) кластера Kafka решают следующие вопросы:
- создание пространства имен для каждого арендатора, т.е. набора топиков, которые сгруппированы вместе под управлением одного субъекта или пользователя;
- настройка топиков, включая определение конфигураций retention и политик очистки в соответствии с требованиями к хранению данных и необходимости их повторного потребления за определенный период;
- защита данных с помощью шифрования, аутентификации и авторизации;
- изоляция арендаторов с помощью квот и ограничений по тарифам;
- мониторинг системных метрик;
- межкластерный обмен данными (георепликация).
Рекомендуется определять логические пространства имен на основе структуры группировки и соглашения об именовании топиков. Наиболее распространенные следующие группировки:
- по команде или организационной единице;
- по проекту или продукту.
Не следует включать в название топика информацию, которая может измениться со временем, например, название потребителя, технические данные или метаданные, в т.ч. параметры конфигурации. Для однотипного именования топиков можно использовать префиксные ACL-списки или настройку create.topic.policy.class.name. Чтобы исключить возможность пользователям Kafka самим создавать топики, надо установить в конфигурации брокера параметр auto.create.topics.enable в значение false.
Для того, чтобы нагрузки одного арендатора не мешали другим пользователям кластера Kafka, администратора настраивают квоты, ограничивающие потребление ресурсов. Kafka поддерживает различные типы клиентских квот, которые применяются независимо от того, в какие топики клиент пишет или из каких читает данные. Квотирование – довольно удобный и эффективный инструменто распределения ресурсов в многопользовательском кластере. Например, квоты частоты запросов ограничивают влияние пользователя на использование ЦП брокера, лимитируя время, которое брокер тратит на обработку запросов для этого пользователя. В большинстве случаев изоляция пользователей с помощью квоты частоты запросов более эффективна, чем квоты входящей/исходящей пропускной способности сети. Это обусловлено тем, что чрезмерное использование ЦП брокера для обработки запросов снижает эффективную пропускную способность брокера. Кроме того, администраторы также могут определять квоты на операции с топиками (создание, удаление и изменение), чтобы предотвратить перегрузку кластеров Kafka. Kafka также поддерживает различные типы серверных квот на стороне брокера. Например, можно установить ограничение на скорость, с которой брокер принимает новые соединения, задать максимальное количество соединений на брокера или ограничить максимальное количество соединений, разрешенных с определенного IP-адреса.
Еще одним вариантом управления мультипользовательским кластером Kafka с изоляцией данных между арендаторами является развертывание этой платформы потоковой передачи событий на Kubernetes. Для этого используется фреймворк Strimzi, о котором мы поговорим далее.
Использование Strimzi для Kubernetes
Strimzi — это проект с открытым исходным кодом, который упрощает развертывание, управление и использование Apache Kafka на Kubernetes и OpenShift. Он предоставляет набор операторов Kubernetes, которые автоматизируют задачи, связанные с управлением кластерами Kafka. Например, оператор кластера управляет жизненным циклом кластеров Kafka, включая развертывание, обновление и удаление. Он также следит за состоянием кластера и автоматически восстанавливает его в случае сбоев. Для управления пользователями и топиками Kafka также есть соответствующие операторы, обеспечивая возможность их автоматического создания, обновления и удаления. Подробнее об операторах Strimzi мы писали здесь.
Strimzi поддерживает TLS-протокол для зашифрованной связи между своими компонентами. Чтобы настроить зашифрованную по протоколу TLS связь между Kafka и клиентами, необходимо настроить слушатели Kafka в пользовательском ресурсе. Слушатели Kafka используют аутентификацию для обеспечения безопасного клиентского подключения к кластеру Kafka. Клиенты также могут быть настроены для взаимной аутентификации. Учетные данные безопасности создаются и управляются оператором кластера и пользователя. Strimzi поддерживает все механизмы аутентификации Kafka: mTLS (на слушателях с шифрованием TLS), SASL, SCRAM-SHA-512, на основе токенов OAuth 2.0, а также пользовательская аутентификация. Также поддерживаются следующие механизмы авторизации для контроля операций, разрешенных на брокерах Kafka определенным клиентам или пользователям: простая авторизация на правилах ACL-списков, OAuth 2.0, Open Policy Agent и пользовательская авторизация.
При установке нескольких операторов Strimzi в одном кластере Kubernetes они могут попытаться управлять одними и теми же ресурсами одновременно. Это может привести к конфликтам и непредсказуемому поведению в кластере. Конфликты могут возникать даже при развертывании операторов Strimzi в разных пространствах имен в одном кластере Kubernetes. Хотя пространства имен обеспечивают некоторую степень изоляции ресурсов, некоторые ресурсы, управляемые оператором Strimzi, такие как пользовательские определения ресурсов (CRD) и роли, имеют область действия в масштабе кластера. Кроме того, установка нескольких операторов с разными версиями может привести к проблемам совместимости между операторами и кластерами Kafka, которыми они управляют. Различные версии операторов Strimzi могут вносить изменения, исправления ошибок или улучшения, которые не являются обратно совместимыми. Чтобы избежать проблем, связанных с установкой нескольких операторов Strimzi в кластере Kubernetes, рекомендуется соблюдать следующие правила:
- устанавливать оператор Strimzi в отдельном пространстве имен от кластера Kafka и ее компонентов, которыми оператор управляет, чтобы обеспечить четкое разделение ресурсов и конфигураций;
- использовать один оператор Strimzi для управления всеми экземплярами Kafka в кластере Kubernetes;
- обновлять оператор Strimzi и поддерживаемую версию Kafka как можно чаще, чтобы отразить последние функции и улучшения.
Освойте администрирование и эксплуатацию Apache Kafka на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Администрирование кластера Kafka
- Администрирование Apache Kafka в Kubernetes
- Apache Kafka для инженеров данных
Источники
