Как развернуть Apache Airflow на Kubernetes с Helm и синхронизировать DAGs из Git?

Apache Airflow является мощным инструментом для программного создания, планирования и мониторинга сложных рабочих процессов. В условиях современной инфраструктуры, особенно при работе с большими объемами данных и сложными ETL/ELT процессами, его развертывание и управление требуют надежных и масштабируемых решений. Kubernetes стал де-факто стандартом для оркестрации контейнеризированных приложений, предлагая гибкость, отказоустойчивость и эффективное использование ресурсов.

Саммари статьи

ChatGPT

Google AI

Grok

Perplexity

Для упрощения развертывания и управления сложными приложениями, такими как Airflow, в экосистеме Kubernetes активно используется Helm – менеджер пакетов, позволяющий определять, устанавливать и обновлять даже самые сложные Kubernetes-приложения с помощью Helm-чартов. Одним из ключевых аспектов эффективного использования Airflow является удобная и автоматизированная доставка DAG-файлов. Интеграция с системами контроля версий, такими как Git, через механизм Git Sync, позволяет поддерживать актуальность рабочих процессов, обеспечивая версионирование и совместную разработку.

В этом руководстве мы подробно рассмотрим, как развернуть Apache Airflow на Kubernetes с использованием официального Helm-чарта, а также настроить синхронизацию DAG-файлов непосредственно из Git-репозитория, обеспечивая надежную и автоматизированную среду для ваших рабочих процессов.

Основы развертывания Apache Airflow с Helm на Kubernetes

Для начала работы с Apache Airflow на Kubernetes с использованием Helm, первым шагом является добавление официального репозитория Helm-чартов Airflow. Это позволит Helm находить и устанавливать чарт Airflow.

1. Добавление репозитория:

   helm repo add apache-airflow https://airflow.apache.org/charts
   helm repo update
   

После успешного добавления репозитория можно приступить к первоначальной установке Airflow. Для этого используется команда helm install. Рекомендуется создать отдельное пространство имен (namespace) для Airflow.

2. Первоначальная установка:

   helm install my-airflow apache-airflow/airflow --namespace airflow --create-namespace
   

Эта команда развернет базовую конфигурацию Airflow. Однако для более детальной настройки, такой как выбор исполнителя (например, KubernetesExecutor), настройка базы данных, ресурсов или количества реплик компонентов (Webserver, Scheduler, Worker), необходимо использовать файл values.yaml. Вы можете сгенерировать базовый values.yaml с помощью helm show values apache-airflow/airflow > values.yaml и затем передать его при установке: helm install my-airflow apache-airflow/airflow -f values.yaml --namespace airflow.

Подготовка и добавление репозитория Helm-чарта Airflow

Для начала работы с развертыванием Apache Airflow через Helm, первым шагом является добавление официального репозитория Helm-чартов Airflow. Это позволит Helm находить и устанавливать чарт Airflow:

helm repo add apache-airflow https://airflow.apache.org/charts

Эта команда добавляет репозиторий с именем apache-airflow, указывая на официальный источник чартов Apache Airflow. После добавления репозитория необходимо обновить локальный кэш Helm, чтобы убедиться, что все доступные чарты и их версии актуальны:

helm repo update

Успешное выполнение этих команд подтверждает, что репозиторий Apache Airflow теперь доступен для использования. Вы можете проверить наличие чарта Airflow и его доступные версии, выполнив:

helm search repo apache-airflow/airflow

Эта команда выведет список доступных версий чарта Airflow, готовых к установке, что является индикатором успешной подготовки.

Первоначальная установка Airflow и базовые настройки values.yaml

После добавления репозитория Helm-чартов Airflow, можно приступить к первоначальной установке. Для этого используется команда helm install, которая развернет все необходимые компоненты Airflow в вашем кластере Kubernetes. Важнейшим элементом при установке является файл values.yaml, который позволяет переопределять параметры по умолчанию, заданные в Helm-чарте.

Пример базовой команды установки:

helm install airflow apache-airflow/airflow --namespace airflow --create-namespace -f values.yaml

Здесь:

• airflow – это имя вашего релиза Helm (можно выбрать любое).

• apache-airflow/airflow – указывает на чарт Airflow из добавленного репозитория.

• --namespace airflow --create-namespace – создает пространство имен airflow и развертывает в нем компоненты.

• -f values.yaml – указывает на ваш файл конфигурации.

В файле values.yaml для первоначальной установки рекомендуется настроить следующие параметры:

• executor: Для production-среды часто выбирают CeleryExecutor или KubernetesExecutor. Для быстрого старта можно оставить SequentialExecutor или LocalExecutor (но они не подходят для распределенных нагрузок).

• webserver.extraEnv: Добавьте переменную окружения AIRFLOW__CORE__LOAD_EXAMPLES: "False", чтобы отключить загрузку примеров DAG-файлов Airflow, которые могут засорять интерфейс.

• postgresql.enabled: Для быстрого старта можно установить true, чтобы развернуть встроенную базу данных PostgreSQL. Однако для production-среды настоятельно рекомендуется использовать внешнюю базу данных (например, облачный сервис или отдельный кластер PostgreSQL).

Пример values.yaml для базовой установки:

executor: KubernetesExecutor

webserver:
  extraEnv:

    - name: AIRFLOW__CORE__LOAD_EXAMPLES
      value: "False"

postgresql:
  enabled: true
  persistence:
    enabled: true
    size: 10Gi

scheduler:
  replicas: 1

worker:
  replicas: 1

После выполнения команды helm install Airflow будет развернут, но пока без синхронизации DAG-файлов из Git.

Настройка синхронизации DAG-файлов из Git (Git Sync)

Для эффективного управления рабочими процессами в production-среде критически важна автоматическая синхронизация DAG-файлов. Helm-чарт Apache Airflow предоставляет встроенную функциональность Git Sync, которая позволяет автоматически подтягивать DAG-файлы из указанного Git-репозитория.

Конфигурация параметров Git Sync в Helm-чарте Airflow

Настройка Git Sync осуществляется через файл values.yaml. Основные параметры включают:

• gitSync.enabled: true: Активирует функциональность Git Sync.

• gitSync.repo: URL вашего Git-репозитория (например, https://github.com/your-org/your-dags-repo.git).

• gitSync.branch: Ветка, из которой будут синхронизироваться DAG-файлы (например, main).

• gitSync.subPath: Опционально, если DAG-файлы находятся в поддиректории репозитория (например, dags).

• gitSync.period: Интервал синхронизации в секундах (например, 30).

• gitSync.privateKeySecret: Имя секрета Kubernetes, содержащего SSH-ключ для доступа к приватным репозиториям.

Пример конфигурации в values.yaml:

gitSync:
  enabled: true
  repo: "https://github.com/apache/airflow.git"
  branch: "main"
  subPath: "dags/example_dags"
  period: 30
  # privateKeySecret: "airflow-git-ssh-key"

Принцип работы Git Sync: initContainer и sidecar

Git Sync реализуется с использованием двух типов контейнеров в подах Airflow (webserver, scheduler, worker):

1. initContainer: Этот контейнер запускается первым при старте пода. Его задача — выполнить первоначальное клонирование указанного Git-репозитория в общий том (Persistent Volume Claim), который затем монтируется всеми основными контейнерами Airflow.

2. sidecar: После initContainer запускается sidecar-контейнер, который работает параллельно с основными контейнерами Airflow. Он периодически (с интервалом, заданным в gitSync.period) проверяет наличие обновлений в Git-репозитории и подтягивает их в тот же общий том. Таким образом, все компоненты Airflow всегда имеют доступ к актуальным версиям DAG-файлов.

Конфигурация параметров Git Sync в Helm-чарте Airflow

Для активации и настройки синхронизации DAG-файлов из Git-репозитория необходимо внести соответствующие изменения в файл values.yaml Helm-чарта Airflow. Ключевые параметры, отвечающие за Git Sync, находятся в секции gitSync:

• gitSync.enabled: Установите в true, чтобы включить функциональность Git Sync.

• gitSync.repo: URL вашего Git-репозитория (например, https://github.com/your-org/your-dags.git или git@github.com:your-org/your-dags.git).

• gitSync.branch: Ветка репозитория, из которой будут синхронизироваться DAG-файлы (например, main или master).

• gitSync.subPath: Опциональный путь внутри репозитория, где хранятся DAG-файлы. Если DAGs находятся в корне, этот параметр можно опустить или оставить пустым.

• gitSync.period: Интервал синхронизации в секундах (например, 300 для 5 минут).

Для доступа к приватным репозиториям потребуется настроить аутентификацию. Это можно сделать с помощью SSH-ключа или учетных данных HTTPS:

• SSH-доступ: Создайте Kubernetes Secret, содержащий ваш приватный SSH-ключ (например, airflow-git-ssh-key), и укажите его имя в gitSync.sshKeySecret. Также может потребоваться gitSync.knownHosts.

• HTTPS-доступ с токеном/паролем: Создайте Kubernetes Secret с именем пользователя и паролем/токеном (например, airflow-git-credentials) и укажите его в gitSync.credentialsSecret.

Пример конфигурации в values.yaml:

gitSync:
  enabled: true
  repo: "https://github.com/apache/airflow-helm-repo-example.git"
  branch: "main"
  subPath: "dags"
  period: 300
  # Для приватных репозиториев (выберите один метод):
  # sshKeySecret: "airflow-git-ssh-key"
  # knownHosts: "airflow-git-known-hosts"
  # credentialsSecret: "airflow-git-credentials"

После настройки этих параметров и обновления Helm-релиза Airflow, initContainer и sidecar-контейнеры Git Sync начнут свою работу, обеспечивая актуальность ваших DAG-файлов.

Принцип работы Git Sync: initContainer и sidecar

Механизм Git Sync в Helm-чарте Airflow реализован с использованием двух ключевых паттернов Kubernetes: initContainer и sidecar контейнеров. Это обеспечивает как первоначальную загрузку DAG-файлов, так и их последующую непрерывную синхронизацию.

1. initContainer: При первом запуске пода (например, webserver, scheduler или worker) initContainer выполняет однократную операцию клонирования указанного Git-репозитория в общий том. Этот том монтируется ко всем основным контейнерам пода, делая DAG-файлы доступными сразу после старта.

   Реклама

2. sidecar контейнер: После успешного завершения initContainer запускается основной контейнер пода, а рядом с ним — sidecar контейнер Git Sync. Этот sidecar постоянно работает в фоновом режиме, периодически (с интервалом, заданным в values.yaml) выполняя git pull для обновления DAG-файлов в том. Таким образом, любые изменения в Git-репозитории автоматически подтягиваются в работающие поды Airflow без необходимости их перезапуска.

Такой подход гарантирует, что все компоненты Airflow всегда работают с актуальной версией DAG-файлов, обеспечивая консистентность и упрощая процесс развертывания новых рабочих процессов.

Оптимизация и управление Airflow в Production-среде

Переходя к production-среде, ключевым аспектом является обеспечение надежности и масштабируемости. Для Metastore Airflow критически важно использовать внешнюю базу данных, такую как PostgreSQL или управляемые облачные сервисы (например, AWS RDS, Google Cloud SQL). Это гарантирует отказоустойчивость, масштабируемость и сохранность метаданных Airflow независимо от жизненного цикла подов, в отличие от встроенной SQLite, которая не подходит для production.

Для хранения логов Airflow и других персистентных данных необходимо настроить persistence в values.yaml, используя Persistent Volumes (PV) и Persistent Volume Claims (PVC). Это предотвращает потерю данных при перезапуске подов. Оптимальное выделение ресурсов (CPU и памяти) для компонентов webserver, scheduler и worker через секцию resources в values.yaml также является обязательным для стабильной работы.

Обновление DAG-файлов, как мы уже выяснили, происходит автоматически благодаря Git Sync. Для обновления версии самого Airflow или Helm-чарта достаточно изменить соответствующие параметры (image.tag для версии Airflow или chart.version для чарта) в values.yaml и выполнить команду helm upgrade.

Рекомендации для production: внешняя база данных, персистентность и ресурсы

Для обеспечения надежности и масштабируемости Airflow в production-среде крайне важно использовать внешнюю базу данных для Metastore. Это гарантирует высокую доступность, упрощает резервное копирование и восстановление, а также позволяет масштабировать базу данных независимо от Airflow. Рекомендуется использовать управляемые сервисы, такие как AWS RDS (PostgreSQL) или Google Cloud SQL, либо развернуть собственный кластер PostgreSQL с высокой доступностью. Конфигурация осуществляется через параметры externalDatabase.* в values.yaml.

Персистентность логов задач Airflow критически важна для отладки и аудита. Настройте persistence.enabled: true для секции logs и укажите соответствующий storageClass и size для Persistent Volume Claims (PVCs). Это гарантирует, что логи сохранятся даже при перезапуске подов или узлов Kubernetes.

Оптимальное выделение ресурсов (CPU и памяти) для компонентов webserver, scheduler и worker является ключом к стабильной работе. Установите адекватные resources.requests и resources.limits в values.yaml для каждого компонента. Недостаток ресурсов может привести к замедлению пользовательского интерфейса, задержкам в планировании задач и сбоям воркеров. Мониторинг и итерационная корректировка этих параметров помогут достичь оптимальной производительности.

Обновление DAG-файлов и версий Airflow через Helm

После того как мы обеспечили стабильность и персистентность, следующим шагом является эффективное управление обновлениями. Обновление DAG-файлов, благодаря настроенному Git Sync, происходит практически автоматически. Любые изменения, внесенные и закоммиченные в указанный Git-репозиторий, будут автоматически синхронизированы с подами Airflow (webserver, scheduler, worker) через sidecar-контейнер Git Sync. Это обеспечивает непрерывную и бесшовную доставку нового или измененного кода DAG без ручного вмешательства.

Для обновления самой версии Apache Airflow или изменения конфигурации Helm-чарта необходимо использовать команду helm upgrade. Перед этим рекомендуется обновить локальный репозиторий Helm-чарта: helm repo update. Затем следует внести необходимые изменения в ваш файл values.yaml, например, обновив тег образа Airflow (image.tag) до новой версии. После этого выполните команду:

helm upgrade [RELEASE_NAME] apache-airflow/airflow -f values.yaml

Крайне важно тестировать обновления в staging-среде перед применением в production, особенно при переходе на мажорные версии Airflow, которые могут включать изменения в схеме базы данных или API.

Альтернативные методы доставки DAGs и устранение проблем

Хотя Git Sync является мощным и рекомендуемым методом для синхронизации DAG-файлов, существуют и другие подходы, которые могут быть полезны в определенных сценариях:

• Kubernetes ConfigMap: Для небольшого количества статичных DAG-файлов можно использовать ConfigMap. DAG-файлы встраиваются непосредственно в ConfigMap, который затем монтируется в поды Airflow. Однако этот метод менее гибок, не масштабируется для большого объема DAGs и требует ручного обновления ConfigMap при каждом изменении, что делает его менее подходящим для production-среды.

• Облачные объектные хранилища (S3, GCS, Azure Blob Storage): В облачных средах популярным методом является хранение DAG-файлов в объектных хранилищах. Airflow может быть настроен на чтение DAGs непосредственно из этих источников, часто с помощью sidecar-контейнера или встроенных плагинов. Это обеспечивает высокую доступность, масштабируемость и интеграцию с облачной инфраструктурой, но требует настройки соответствующих разрешений и механизмов синхронизации.

При развертывании и синхронизации DAGs могут возникнуть следующие распространенные проблемы:

• Проблемы с Git Sync: Неверные учетные данные (SSH-ключи, токены), отсутствие доступа к репозиторию или проблемы с known_hosts. Проверьте логи initContainer или sidecar Git Sync для диагностики.

• Ошибки парсинга DAGs: Синтаксические ошибки в Python-коде DAGs, отсутствие необходимых Python-пакетов или неправильные импорты. Логи планировщика (scheduler) содержат подробную информацию об ошибках парсинга.

• Недостаток ресурсов: Поды webserver, scheduler или worker могут падать из-за нехватки CPU или памяти. Увеличьте лимиты ресурсов в values.yaml для соответствующих компонентов.

• Проблемы с разрешениями: Неправильно настроенные RBAC-правила Kubernetes или файловые разрешения внутри подов могут препятствовать работе Airflow или доступу к DAG-файлам.

Другие подходы к доставке DAG-файлов (ConfigMap, облачные хранилища)

Хотя Git Sync является мощным и широко используемым механизмом для синхронизации DAG-файлов, существуют и другие подходы, которые могут быть более подходящими в зависимости от специфики проекта и инфраструктуры:

• Kubernetes ConfigMap: Для небольшого количества статичных DAG-файлов, которые не требуют частых изменений, можно использовать ConfigMap. DAG-файлы встраиваются непосредственно в ConfigMap, который затем монтируется в контейнеры Airflow (webserver, scheduler, worker) как том. Этот метод прост в реализации, но имеет ограничения по размеру (обычно 1 МБ) и менее удобен для частых обновлений.

• Облачные объектные хранилища (S3, GCS, Azure Blob Storage): Для масштабных и динамичных сред, особенно в облачных инфраструктурах, популярным решением является использование объектных хранилищ. DAG-файлы загружаются в бакет, а Airflow настраивается на их чтение (например, через плагины или кастомные операторы). Это обеспечивает высокую масштабируемость, надежность и простоту управления версиями DAG-файлов, а также позволяет легко интегрироваться с CI/CD пайплайнами для автоматической загрузки обновлений.

Распространенные проблемы при развертывании и синхронизации DAGs

При развертывании Airflow на Kubernetes и синхронизации DAGs могут возникнуть различные проблемы, требующие внимательной диагностики:

• Ошибки Git Sync: Убедитесь в корректности SSH-ключей или токенов доступа, а также URL репозитория и пути к DAGs в values.yaml. Проверьте логи initContainer и sidecar пода scheduler или webserver на наличие ошибок клонирования или синхронизации. Частые причины – неверные разрешения или недоступность репозитория.

• Проблемы с парсингом DAGs: Частые причины – синтаксические ошибки в Python-файлах DAGs или отсутствие необходимых Python-зависимостей. Проверьте логи scheduler на предмет ошибок импорта или парсинга. Убедитесь, что DAG-файлы соответствуют ожидаемой структуре и находятся в правильной директории.

• Недостаток ресурсов: Поды Airflow (особенно scheduler и worker) могут быть OOMKilled или работать медленно из-за недостатка CPU/памяти. Оптимизируйте запросы и лимиты ресурсов в Helm-чарте.

• Проблемы с подключением к метабазе: Убедитесь, что Airflow может подключиться к базе данных (PostgreSQL). Проверьте сетевую доступность, учетные данные и настройки host/port в values.yaml.

Заключение

В данном руководстве мы подробно рассмотрели процесс развертывания Apache Airflow на Kubernetes с использованием Helm-чарта, а также ключевой аспект – синхронизацию DAG-файлов из Git-репозитория. Этот подход обеспечивает высокую степень автоматизации, версионирования и масштабируемости, что критически важно для современных production-сред.

Использование Helm значительно упрощает управление сложными конфигурациями Airflow, а Git Sync гарантирует, что ваши рабочие процессы всегда актуальны и находятся под контролем версий. Следуя изложенным рекомендациям и лучшим практикам, вы сможете построить надежную и эффективную платформу для оркестрации данных, готовую к любым вызовам.