Мы уже писали о преимуществах развертывания Apache NiFi на Kubernetes, а также сложностях практической реализации этого процесса. Сегодня поговорим о контейнеризации реестра NiFi с использованием Helm-диаграмм, а также совмещения с Apache Ranger и Kerberos.
7 главных трудностей развертывания Apache NiFi на Kubernetes
Apache NiFi активно используется дата-инженерами для организации потоковых конвейеров обработки больших данных. Но запустить его в популярной платформе управления контейнерными приложениями Kubernetes не так-то просто. Apache NiFi является stateful-приложением и в большинстве случаев оно развертывается как кластер на «голом железе» или виртуальной машине. При этом узлы кластера NiFi не разделяют и не реплицируют результаты обработки между собой. Это усложняет процесс контейнеризации. Обойти эти ограничения NiFi, связанных с его работой в кластерном режиме, позволит установка дополнительного сервиса синхронизации метаданных Apache Zookeeper, чтобы разделить конвейер на отдельные экземпляры NiFi, каждый из которых будет работать как автономный. Таким образом можно создать стабильные экземпляры NiFi в Kubernetes, и легко управлять их конфигурациями из репозитория, используя, например, диаграммы Helm с выделенным файлом значений. Напомним, Helm – это менеджер пакетов Kubernetes, которое помогает установить приложения Kubernetes и управлять их жизненным циклом с помощью перехватчиков (hooks) версионирования, повторного использования шаблонов и пакетов предварительно настроенных ресурсов, которые называются диаграммами или чартами (Chart).
Однако, при развертывании Apache NiFi на Kubernetes стоит помнить о высокой нагрузке операций ввода-вывода из-за чтения и записи потоковых файлов на диск, что мы рассматривали здесь. Это особенно заметно при большом количестве конвейеров, которые постоянно считывают данные, выполняют над ними операции, маршрутизируют или планируют и отслеживают процессы на основе содержимого Flow File. Это требует производительного хранилища данных типа локального дискового SSD, что будет работать быстро но не обеспечит высокой доступности сервиса.
Также требуется высокая производительность сети между кластерами Kubernetes и потребителями/источниками данных для NiFi, например, кластер Hadoop или Kafka. Это особенно важно при сохранении файла, например, в HDFS с последующим перестроением таблицы Hive. Здесь также следует задуматься о построении CI/CD-конвейера, который будет включать несколько вопросов: от сборки базового Docker-образа, куда могут входить пользовательские NAR до развертывания в Kubernetes с использованием Helm-диаграмм.
После развертывания на Kubernetes следует предоставить пользователям NiFi доступ к системе. В Kubernetes доступ к приложению предоставляется через сервис, что довольно просто для HTTP, но сложнее с защищенным протоколом HTTPS. В частности, нужно настроить опцию в Ingress – базовом типе ресурса Kubernetes, которая отвечает за прохождение SSL. Он представляет собой набор правил, позволяющий трафику извне достичь сервисов внутри кластера. Ingress и Ingress-контроллер (под Kubernetes с запущенным приложением-контроллером) позволяют создать единую точку входа для трафика и выполняют одновременно роль прокси и балансировщика нагрузки, работая на уровне приложений сетевой модели OSI. Однако, сертификат от Ingress рассматривается NiFi как попытка аутентификации пользователя. Поэтому все будет работать следующим образом: HTTPS-трафик направляется на веб-сервис, ответственный за завершение SSL, и снова шифрует трафик для NiFi.
Генерировать сертификат безопасности можно каждый раз с помощью NiFI Toolkit и запускать его в качестве дополнения к NiFI. Или использовать однажды созданный сертификат, созданное хранилище доверенных сертификатов и хранилище ключей. Хранить все секретные файлы можно как секреты Kubernetes или с использованием соответствующего менеджера типа Google Cloud Secrets Manager, Hashicorp Vault, чтобы смонтировать их в набор состояния NiFi. Если нужно добавить сертификат в хранилище доверенных сертификатов, можно импортировать его, повторно загрузив хранилище доверенных сертификатов, или импортировать динамически при каждом запуске.
Запустив NiFi в Kubernetes, важно отслеживать использование его ресурсов и проверять, как он обрабатывает данные. Для этого отлично подойдут специализированные средства мониторинга системных метрик, например, Prometheus. Чтобы избежать проблем с утечкой памяти, рекомендуется установить минимальное значение для JVM на одном уровне, оставив большую разницу между значением памяти JVM и пределом ОЗУ для всего пода Kubernetes.
Реестр и безопасность
Реестр Apache NiFi играет роль Git-репозитория для потоковых конвейеров, храня всю информацию об изменениях в своей собственной базе данных – по умолчанию это H2, но вместо нее также можно настроить PostgreSQL или MySQL. На практике сложности возникают при хранении и обновлении хранилища ключей и доверенных сертификатов, аналогично с самим Apache NiFi. Развертывание реестра Apache NiFi на Kubernetes выполняется с использованием готовой Helm-диаграммы, доступной на Github. Helm-чарт представляет собой пакет предварительно настроенных ресурсов Kubernetes – ЦП и памяти для работы контейнера, в который упаковано приложение и среда для его корректной работы, включая все нужные библиотеки, переменные окружения и пр. Согласно DevOps-идеям о непрерывной интеграции и поставке, а также управлению инфраструктурой как кодом, каждый новый релиз контейнерного приложения в кластере, работающего в кластере Kubernetes, можно рассматривать как chart. Один чарт может быть установлен в одном и том же кластере много раз, при этом при каждой новой установке Helm создает новый релиз в Kubernetes. Для поиска новых чартов есть поиск Helm по репозиториям.
Как и сам Apache NiFi, его реестр также является приложением с отслеживанием состояния. Поэтому нужно хранилище для локально клонированного репозитория и базы данных Git. Вместо H2 по умолчанию лучше использовать PostgreSQL или MySQL, которые надежнее H2, и управляются отдельно от самого реестра NiFi.
Важным аспектом любой платформы данных корпоративного уровня является управление разрешениями для всех служб. В самой базовой настройке используется управление разрешениями, пользователями и группами непосредственно в Apache NiFi или его реестре. Но можно использовать что-то более гибкое, например, Apache Ranger – систему мониторинга и управления комплексной защитой данных на платформе Hadoop.
Ranger позволяет настроить политики NiFi и его реестра непосредственно в графическом интерфейсе или через REST API и просмотреть данные об отказе в доступе для любого пользователя. В этом случае нужно настроить Ranger Audit в NiFi и подключение к Infra Solr и HDFS, которые используются для хранения горячих и холодных данных об аудите. Сделать это можно следующим образом:
- Сперва для соединения Ranger и NiFi нужно создать новый Docker-файл с плагином Ranger для каждого экземпляра NiFi. Лучший всего для этого создать многоэтапный Docker-файл, где будет собран плагин, а затем добавить его на слой с самим NiFi.
- Далее следует добавить новые политики в Ranger, которые можно протестировать просто во время первого запуска защищенной установки.
- Затем создаются все файлы, необходимые Ranger, такие как конфигурация его подключения к NiFi, настройки аудита и обновление авторизаторов NiFi для использования плагина Ranger. Здесь следует запустить NiFi и проверить его работу.
- Наконец, необходимо настроить Kerberos в NiFi по завершении процесса развертывания, помня о связи между кластером Kubernetes и провайдерами сервисов Kerberos типа FreeIPA или AD. Важно создать таблицу ключей, которая не имеет их в своем принципале, чтобы упростить управление таблицами ключей для NiFi. Также нужно смонтировать файл conf и установить клиентские пакеты Kerberos.
Читайте в нашей новой статье, какие cybersecurity-улучшения внесены в июньский релиз фреймворка. А освоить администрирование и эксплуатацию Apache NiFi для построения эффективных ETL-конвейеров потоковой аналитики больших данных вам помогут специализированные курсы в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
