В этой статье для дата-инженеров и администраторов кластеров разберем, как автоматически масштабировать поды Kubernetes с Apache AirFlow в зависимости от метрик рабочей нагрузки из внешней платформы Datadog с помощью демона StatsD, а также ресурса и контроллера HorizontalPodAutoscaler.
Автоматическое горизонтальное масштабирование в Kubernetes
Одна из сильных сторон Kubernetes заключается в его способности обеспечивать эффективное автоматическое масштабирование ресурсов с учетом значений сервисных метрик. Например, необходимо отслеживать и автоматически масштабировать рабочие процессы Apache Airflow на основе метрик из платформы мониторинга и безопасности облачных приложений Datadog. Она обеспечивает непрерывный мониторинг и сквозную трассировку метрик, а также логов пользовательских приложений, инфраструктуры и сторонних сервисов, позволяя защитить системы и избежать простоев. Прежде чем реализовать эту идею, рассмотрим, как реализуется автоматическое горизонтальное масштабирование в Kubernetes.
Горизонтальное автомасштабирование в Kubernetes выполняется с помощью HorizontalPodAutoscaler (HPA), который автоматически развертывает больше подов при увеличении рабочей нагрузки. Это отличается от вертикального масштабирования, что для Kubernetes означает выделение большего количества ресурсов (памяти или ЦП) уже запущенным и работающим подам. Чем HPA отличается от вертикального автомасштабирования, читайте в нашей новой статье.
При снижении нагрузки, если количество подов больше настроенного минимума, HorizontalPodAutoscaler дает указание ресурсу уменьшить масштаб. Это очень полезно при оптимизации потоковых приложений Apasche Spark Structured Streaming, о чем мы рассказываем здесь.
HPA реализован как ресурс Kubernetes API и контроллер. Ресурс определяет поведение контроллера. Контроллер периодически корректирует желаемый масштаб в соответствии с наблюдаемыми показателями, такими как среднее использование ЦП, среднее потребление памяти или любой другой пользовательской метрикой.
Kubernetes реализует горизонтальное автомасштабирование подов как цикл управления, который работает с перерывами. Интервал задается параметром —horizontal-pod-autoscaler-sync-period для kube-controller-manager и по умолчанию равен 15 секунд. Периодически диспетчер контроллера запрашивает использование ресурсов по метрикам, указанным в каждом определении HorizontalPodAutoscaler. Диспетчер контроллера получает метрики из API метрик ресурсов для каждого пода или из API пользовательских метрик для всего остального, чтобы вычислить используемое значение и сравнить с целевым.
Обычно HorizontalPodAutoscaler используется для настройки получения метрик из агрегированных API metrics.k8s.io, custom.metrics.k8s.io или external.metrics.k8s.io. API metrics.k8s.io обычно предоставляется надстройкой Metrics Server, которую необходимо запускать отдельно. Поддержка API метрик объясняет гарантии стабильности и статус поддержки для этих различных API. Контроллер HPA получает доступ к соответствующим ресурсам рабочей нагрузки, которые поддерживают масштабирование (например, Deployments и StatefulSet). У каждого из этих ресурсов есть подресурс с именем scale, интерфейс, который позволяет динамически устанавливать количество реплик и проверять каждое из их текущих состояний.
Таким образом, чтобы автоматически менять количество подов с Apache AirFlow в кластере Kubernetes в зависимости от рабочей нагрузки с помощью HPA, нужно организовать отслеживание сервисных метрик. Как это сделать с помощью платформы Datalog, рассмотрим далее.
Сбор и мониторинг метрик Apache AirFlow cо StatsD и Datadog
Для организации системного мониторинга Apache AirFlow позволяет отправлять метрики в StatsD –сетевую системную службу (демон) на платформе Node.js, который по UDP или TCP прослушивает статистику, такую как счетчики и таймеры, чтобы передать сводные данные в одну или несколько подключаемых серверных служб, например, Graphite или Datadog. В StatsD каждая статистика находится в своей корзине (bucket) и имеет значение, интерпретация которого зависит от модификатора. По истечении тайм-аута интервала сброса config.flushInterval, по умолчанию равного 10 секунд, статистика агрегируется и отправляется в систему мониторинга.
Для использования open-source проекта StatsD в Apache AirFlow необходимо сперва установить его через менеджер пакетов pip: pip install ‘apache-airflow[statsd]’. Далее нужно определить метрики для отслеживания. Например, отправлять в Datadog метрики исполнителя, если интересуют данные по запущенным задачам. Для этого следует добавить строки в файл конфигурации airflow.cfg:
[metrics] statsd_on = True statsd_host = localhost statsd_port = 8125 statsd_prefix = airflow datadog_enabled = true# Allow List of Metrics allow_list: executor# Datadog Tags of the environment datadog_tags: "statsd_group:datainfra,statsd_env:production"
В Kubernetes ресурс External Metrics Provider позволяет системам мониторинга, таким как Datadog, предоставлять метрики приложений контроллеру HPA. Таким образом, автоматическое горизонтальное масштабирование подов с Airflow в среде Kubernetes сводится к следующим шагам:
- настройка агента кластера Datadog;
- включение статистики AirFlow;
- создание пользовательского определения ресурса (CRD) для метрик Datadog;
- применение HorizontalPodAutoscaler в зависимости от значений метрик.
Напомним, в Kubernetes пользовательские ресурсы создаются как экземпляры API, добавляемые определениями пользовательских ресурсов (CRD, Custom Resource Definition) для расширения ресурсов. CRD для метрик Datadog может выглядеть следующим образом:
resource "kubectl_manifest" "DatadogMetric" {
yaml_body = <<YAML
apiVersion: datadoghq.com/v1alpha1
kind: DatadogMetric
metadata:
name: running-tasks
namespace: production
spec:
query: avg:airflow.executor.running_tasks{*}.rollup(max, 60)
YAML
}
Проверить значение метрики можно, отправив необработанный запрос GET на сервер API Kubernetes с помощью CLI-инструмента управления кластером платформы контейнерной виртуализации kubectl: kubectl get —raw «/apis/external.metrics.k8s.io/v1beta1″ | jq .
Чтобы создать HPA с помощью DatadogMetric, необходимо предоставить executor.running_tasks, которые будут запрашиваться из API метрик и масштабировать рабочие процессы Airflow, если текущих запущенных задач больше 1. HPA поможет сэкономить на кластере за счет уменьшения количества активных узлов по мере уменьшения количества подов. Тогда набор конфигурации для упаковки в диаграммы Helm со всеми определениями ресурсов, необходимыми для запуска приложения, инструмента или службы внутри кластера Kubernetes будет выглядеть так:
workers: enabled: true replicas: 1 resources: requests: cpu: 800m memory: 3.5Gi autoscaling: enabled: true maxReplicas: 2 metrics: - type: External external: metric: name: "datadogmetric@production:running-tasks" target: type: AverageValue averageValue: 1
Код курса
ADH-AIR
Ближайшая дата курса
Продолжительность
ак.часов
Стоимость обучения
0 руб.
Читайте в нашей новой статье про автоматизацию развертывания конвейеров AirFlow с помощью новой версии Helm Сhart. А все практические детали по администрированию и эксплуатации Apache AirFlow для организации ETL/ELT-процессов в аналитике больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- https://medium.com/ni-tech-talk/autoscaling-your-airflow-using-datadog-external-metrics-3decaaa3072c
- https://docs.datadoghq.com/
- https://airflow.apache.org/docs/apache-airflow/stable/logging-monitoring/metrics.html
- https://github.com/statsd/statsd
- https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
