5 проблем дата-инженеров Apache NiFi на Kubernetes и как их решить

В рамках нового курса Эксплуатация Apache NIFI, сегодня разберем особенности развертывания этого маршрутизатора потоков Big Data на платформе управления контейнерными приложениями Kubernetes. Советы дата-инженерам, как сократить расходы на AWS, избежать сбоев узлов и потерь данных, обеспечить безопасность и автоматическое масштабирование облачного кластера Apache NiFi в Amazon EKS, а также зачем нужны Helm Chart, оператор NiFiKop от Orange и комплексное решение от Cloudera.

Почему нельзя просто так взять и развернуть Apache NiFi на Kubernetes

Контейнеризация приложений сегодня становится стандартом де-факто в области Big Data. Kubernetes (K8s) как мощная платформа управления контейнеризованными приложениями упрощает разработку, тестирование и развертывание, ускоряя эти процессы с помощью упаковки рабочего окружения в автономные модули и обеспечивая безопасность за счет изоляции данных, ресурсов и пользователей. Однако, эта технология не является серебряной пулей для всех сценариев использования и имеет ряд особенностей при совместном использовании с другими фреймворками. В частности, соединить Apache NiFi и Kubernetes не так-то просто из-за разных архитектурных подходов, на которых построены эти платформы. Apache NiFi представляет собой монолитную stateful-систему с долгоживущими процессами, которые работают с потоками данных. Это радикально отличается от микросервисной парадигмы Kubernetes. Поэтому при развертывании Apache NiFi на Kubernetes в облаке AWS можно столкнуться со следующими проблемами [1]:

высокое потребление ресурсов облачного кластера AWS EKS (Elastic Cloud Kubernetes);
потеря устойчивости;
трудности обеспечения информационной безопасности;
отсутствие горизонтального масштабирования по умолчанию;
сложности развертывания и эксплуатации.

Каждую из перечисленных проблем мы подробно рассмотрим далее и отметим способы ее решения.

Как сэкономить на кластере AWS EKS: эффективная утилизация ресурсов

Проблема неэффективного использовании ресурсов характерна для многих корпоративных решений стека Big Data. Особенно это проявляется при их развертывании в облаках, что приводит к увеличению расходов на эту инфраструктуру. Подобные неиспользованные бесхозные ресурсы часто случаются во время разработки и выпуска обновлений. При этом следует учитывать ограничения и возможности самой PaaS-платформы. К примеру, в AWS есть лимит ресурсов для каждой учетной записи. Поэтому в случае эксплуатации Apache NiFi в AWS целесообразно привязать его к учетным записям домена, чтобы его пользователи самостоятельно развертывали фреймворк самостоятельно в своих аккаунтах.

В этом же сценарии случается ситуация с несбалансированным распределением ресурсов на потоки данных NiFi. По умолчанию все потоки NiFi совместно используют все ресурсы кластера, без ранжирования по приоритетам. Изолировать кластеры NiFi, работающих с разными потоками данных можно с помощью отдельных пространств имен [1].

Устойчивость и потери

При запуске NiFi на Kubernetes эти фреймворки могут конкурировать друг с другом за ресурсы, что чревато потерями данных. В частности, планировщик k8s для обслуживания новых запросов может вытеснять существующие поды, уничтожая имеющиеся на них данные. Избежать этого поможет надежное хранилище, например, AWS EBS (Elastic Block Store) для NiFi-репозиториев, где будут храниться потоковые файлы, контент и данные об их происхождении с отслеживанием состояния. Благодаря встроенным в NiFi механизмам контрольных точек и моментальных снимков потоковых файлов можно возобновить обработку данных в случае сбоя.

Также возможны проблемы с недостатком места на узлах NodeWithImpairedVolumes = true: NoSchedule, когда тома слишком долго находятся в состоянии ожидания и планировщику не удается подключать их по истечении 30-минутного тайм-аута. В этом случае узел становился непригодным для будущего планирования. Это происходит редко, если AWS пытается подключить том из другой зоны доступности для stateful-набора. Исправить такой сбой можно, запустив демон для очистки узла [2].

Также случаются проблемы с потерей состояния, т.к. процессоры NiFi настроены на внешнее управление состоянием с помощью Zookeeper, поды которого вытесняет Kubernetes. Предупредить это можно, выделив Apache Zookeeper вместе с другими общими сервисами (Nifi-Registry, Prometheus, Grafana, Redis) в изолированный кластер EKS. Так запросы планирования k8s для NiFi изолируются от общих служб. Чтобы предотвратить потерю данных о состояниях, Zookeeper также устанавливается с блочным хранилищем AWS EBS. Рекомендуется использовать Zookeeper v3.6.1 и выше в реплицированном режиме, чтобы кворум мог выдержать определенное количество сбоев.

Наконец, поскольку набор состояний для NiFI-подов автоматически вытесняется k8s, то при синхронизации потоков возникает сбой, если есть изменение на еще узле, который еще не работает и не синхронизирован с другими. В результате в пользовательском интерфейсе кластера выводится сообщение об ошибке «Cluster coordinator is still syncing flows». Исправить это можно, синхронизируя потоки flow.xml.gz (authorizers.xml, users.xml) с хранилищем удаленных объектов, например, в AWS S3, и перезапустив под [1].

4 проблемы с безопасностью NiFi на Kubernetes

Балансировщик нагрузки AWS ELB завершает TLS до попадания в целевые узлы EC2 и не передает сертификаты поду обработчика запросов. Для обхода этого ограничения можно использовать внутренний CA-сервер для генерации и предоставления сертификатов подам в NiFi-кластере для обмена данными между модулями через TLS. Также важно решить задачу закрепления сеанса для провайдера NiFi OIDC (OpenID Connect) – протокола проверки подлинности на основе протокола авторизации OAuth 2.0 для безопасного входа пользователей в приложение через сторонний сервис. Объект sessionAffinity для k8s с набором состояний не закрепляет сеанс, поскольку трафик через AWS ELB не знает о таких классификациях и не имеет алгоритма для его обработки. Исправить это можно, перенаправив трафик OIDC-последовательности на нулевой под.

Здесь же имеет место переопределение тайм-аута клиентского сеанса для OIDC: обычно внутренний OIDC-провайдер имеет ограничения на настройку тайм-аута. Обновить тайм-аут перед запросами пользовательского интерфейса NiFi можно с помощью дополнительной системной службы, которая будет перехватывать запрос токена. Также следует обработать выход из набора OIDC-запросов, т.к. внутренний провайдер отправляет такие запросы с разными атрибутами. Перехватив такой запрос, его следует перенаправить к URI выхода из системы запросов для OIDC-провайдера. Подробнее про аутентификацию пользователей NiFi через OIDC-провайдера читайте в нашей новой статье.

Для корпоративного использования полезно интегрировать RBAC с объединенными ролями IAM для NiFi и K8s pod/node. В частности, под NiFi может принимать ограниченные федеративные роли IAM для доступа к данным, что аналогично RBAC-ролям. В этом случае, чтобы сохранить простоту, устойчивость и повторяемость, следует определить RBAC в виде структурированного JSON-файла, также будет поддерживать YAML с ресурсами NiFi для назначения ACL-списков доступа. Например, выделить сторонний демон для обработки конфигурации RBAC с помощью NiFi-toolkit API, который запускается при начальной загрузке и синхронизируется с удаленным кэшем при перезапуске пода.

Еще необходимо решить проблемы с NiFi API при OIDC-аутентификации, к примеру, когда потоки NiFi должны контролироваться другими системами, такими как Airflow. Когда NiFi поддерживает OIDC, запрос API не может быть аутентифицирован без предварительного входа пользователя, что снижает уровень автоматизации. Даже для пользователей сервиса NiFi поддерживает только один путь для настроенного authN, перенаправляющий на URI обнаружения OIDC для входа в систему. Исправить это поможет клиент kubectl, аутентифицированный токеном роли пространства имен служебной учетной записи, выполняющей API набора инструментов nifi на нулевом поде.

Наконец, хотя NiFi и шифрует конфиденциальные данные на диске, здесь не ведется контроль версий. Избежать трудоемкого управления чувствительными данными потоков Big Data вручную поможет менеджер секретов AWS, который загружает секреты в среду контейнера. NiFi может получить к ним доступ как к переменным аргументам реестра [1].

Масштабируемость кластера

Автоматическое масштабирование кластера AWS EKS отлично решает проблемы управления его размером. Настроив автомасштабирование для каждого кластера EKS, их можно изолировать друг от друга. Однако, в этом случае невозможно контролировать время подключения узла EC2 к запросу на масштабирование Kubernetes. Горизонтальный модуль масштабирования подов (HPA) не знает о показателях диска и процессора узлов NiFi, поэтому приходится учитывать их обрабатывая разгрузку с плавным тайм-аутом завершения, чтобы предотвратить потерю данных [1]. Частично эту проблему можно решить с помощью специальных инструментов развертывания NiFi на Kubernetes, о которых мы поговорим далее.

Сложности установки и эксплуатации Apache NiFi на Kubernetes

Наконец, главным условием для использования обоих технологий является уверенной владение каждой из них, что повышает уровень требований к компетенциям дата-инженера. Частично облегчить процесс установки Найфай на Kubernetes поможет специальный Helm – open-source средство упаковки и управления контейнерами. Например, Helm Chart для Apache NiFi для свободного скачивания под лицензией Apache 2.0 с инструкциями по настройке доступен в источнике [3].

Для автоматизированного обслуживания Apache NiFi на Kubernetes можно использовать готовый оператор от корпорации Orange под названием NiFiKop. Он автоматизирует выделение ресурсов, управление, автоматическое масштабирование и обслуживание кластеров Найфай, развернутых в Kubernetes. По сути, NiFiKop – это настраиваемый контроллер Kubernetes, который работает с событиями на объектах NiFiCluster, согласовывая их с ресурсами K8s, необходимыми для развертывания кластера NiFi. NiFiKop как open-source проект доступен для использования под лицензией Apache v2.0 и доступен на GitHub [4].

NiFiKop прослушивает несколько пространств имен, управляя кластерами Nifi в них. С помощью этого оператора можно определять пользователей и группы с их политиками доступа, используя ресурсы K8s, что позволяет полностью автоматизировать настройку кластера NiFi с помощью конфигураций yaml. Наконец, NiFiKop может определять клиента реестра NiFi, контекст параметров и поток данных с использованием ресурсов Kubernetes. Это дает дата-инженеру возможность полностью автоматизировать развертывание DataFlow и управлять его жизненным циклом [5]. Подробнее про оператор NiFiKop читайте в нашей новой статье.

Примечательно, что этот оператор частично решает некоторые следующие проблемы, что мы рассмотрим в отдельной статье. Также подробнее в следующий раз разберем еще одно готовое решение для развертывания Apache NiFi на Kubernetes от компании Cloudera, которая интегрировала движок управления потоками данных в Red Hat OpenShift — комплексный корпоративный K8s [6].

Больше деталей про администрирование и использование Apache NiFi для решения задач дата-инженерии вы узнаете на специализированных курсах для разработчиков, ИТ-архитекторов, дата-инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в нашем лицензированном учебном центре обучения и повышения квалификации в Москве:

Эксплуатация Apache NIFI

Смотреть расписание

Записаться на курс

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники