Открыть сервис
Главная → Блог → KEDA

KEDA

KEDA (сокращение от Kubernetes Event-Driven Autoscaling) — это программное обеспечение с открытым исходным кодом, предназначенное для автоматического масштабирования контейнерных приложений, работающих в среде оркестрации Kubernetes, на основе событий из внешних источников данных. KEDA дополняет встроенные механизмы автоматического масштабирования Kubernetes (Horizontal Pod Autoscaler, HPA) и позволяет запускать рабочие нагрузки (в том числе с нулевым количеством реплик) в ответ на поступление событий от различных систем, таких как очереди сообщений, базы данных, мониторинговые платформы и веб-сервисы.

История и предпосылки создания

Проект KEDA был основан в 2019 году компаниями Microsoft и Red Hat. Основной предпосылкой для его создания стала необходимость эффективного масштабирования приложений, работающих по событийно-ориентированной архитектуре (event-driven architecture), в среде Kubernetes. Встроенный в Kubernetes Horizontal Pod Autoscaler (HPA) ориентирован на масштабирование на основе метрик ресурсов (загрузка CPU, использование памяти) или пользовательских метрик, собираемых с определённой периодичностью. Однако для сценариев, где нагрузка возникает импульсно (например, при обработке сообщений из очереди), такой подход оказывается недостаточно гибким: он не позволяет масштабировать приложения до нуля в отсутствие событий и не может мгновенно реагировать на появление новых сообщений.

KEDA решает эту проблему, выступая в роли посредника между внешними источниками событий и Kubernetes. Первый публичный релиз KEDA (версия 1.0) состоялся в мае 2019 года. В декабре 2020 года проект был принят в инкубатор Cloud Native Computing Foundation (CNCF), а в 2023 году перешёл в статус зрелого проекта CNCF.

Архитектура и принцип работы

KEDA состоит из двух основных компонентов: оператора (Operator) и адаптера метрик (Metrics Adapter).

Оператор KEDA

Оператор — это компонент, который развёртывается в кластере Kubernetes и управляет пользовательскими ресурсами (Custom Resource Definitions, CRD). Он отвечает за активацию и деактивацию Horizontal Pod Autoscaler (HPA) в зависимости от наличия событий. Когда оператор обнаруживает, что внешний источник данных не содержит событий (например, очередь пуста), он масштабирует целевое развёртывание (Deployment) до нуля реплик. При появлении нового события оператор создаёт HPA и увеличивает количество реплик до заданного значения.

Адаптер метрик

Адаптер метрик реализует интерфейс Kubernetes Metrics Server и предоставляет HPA метрики, полученные из внешних источников. Он периодически опрашивает настроенные источники событий (например, длину очереди, количество непрочитанных сообщений) и преобразует эти данные в метрики, понятные HPA. HPA, в свою очередь, использует эти метрики для принятия решения о масштабировании.

ScaledObject и ScaledJob

Пользователь настраивает поведение KEDA через два основных типа пользовательских ресурсов:

  • ScaledObject — применяется для масштабирования развёртываний (Deployments), StatefulSets и Custom Resources. Определяет целевой объект для масштабирования, триггеры (источники событий) и параметры масштабирования (минимальное и максимальное количество реплик, коэффициент масштабирования).
  • ScaledJob — используется для масштабирования заданий (Jobs) в Kubernetes. Позволяет запускать отдельные задания в ответ на каждое событие, что удобно для пакетной обработки данных.

Источники событий (триггеры)

KEDA поддерживает широкий спектр встроенных источников событий (scalers). На момент версии 2.14 насчитывается более 60 различных scalers. Основные категории включают:

Пользователи также могут создавать собственные scalers, реализуя интерфейс на языке Go.

Применение

KEDA используется в сценариях, где требуется гибкое и экономичное масштабирование приложений, обрабатывающих события:

  • Обработка очередей сообщений: приложение, которое читает сообщения из RabbitMQ или Kafka, может масштабироваться от нуля до сотен реплик в зависимости от загруженности очереди. В отсутствие сообщений реплики полностью выключаются, что снижает потребление ресурсов.
  • Пакетная обработка данных: с помощью ScaledJob можно запускать отдельные задания (Jobs) для каждого нового сообщения в очереди, что удобно для ETL-процессов, генерации отчётов или обработки изображений.
  • Веб-приложения с переменной нагрузкой: если веб-сервис получает запросы неравномерно, KEDA может масштабировать его на основе метрик Prometheus или HTTP-запросов.
  • Интернет вещей (IoT): обработка телеметрии с устройств, поступающей импульсами.
  • Микросервисы: автоматическое масштабирование сервисов, реагирующих на события из других сервисов (например, через Kafka).

Преимущества и ограничения

Преимущества

  • Масштабирование до нуля: позволяет экономить ресурсы кластера в периоды отсутствия нагрузки.
  • Быстрая реакция: масштабирование происходит в ответ на появление событий, а не по расписанию.
  • Широкая экосистема: поддержка десятков популярных систем и протоколов.
  • Интеграция с Kubernetes: не требует изменения существующих приложений — достаточно добавить ScaledObject.
  • Открытый исходный код: проект распространяется под лицензией Apache 2.0.

Ограничения

  • Не заменяет HPA: KEDA работает в связке с HPA, а не вместо него. Для метрик, не связанных с событиями (например, загрузка CPU), по-прежнему используется стандартный HPA.
  • Зависимость от внешних систем: для работы KEDA требуется доступ к источникам событий (очереди, базы данных, API).
  • Сложность отладки: при неправильной настройке scalers возможно нежелательное поведение (например, постоянное создание и удаление подов).
  • Ресурсные затраты: оператор и адаптер метрик потребляют ресурсы кластера, хотя и незначительные.

Пример использования

Типичная конфигурация ScaledObject для масштабирования приложения на основе длины очереди RabbitMQ может выглядеть следующим образом:

```yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: rabbitmq-consumer-scaler spec: scaleTargetRef: name: consumer-deployment triggers:

  • type: rabbitmq

metadata: queueName: orders host: amqp://guest:guest@rabbitmq.default.svc.cluster.local:5672 queueLength: '10' ```

В этом примере KEDA будет масштабировать развёртывание consumer-deployment так, чтобы количество реплик было пропорционально длине очереди orders. Когда очередь пуста, количество реплик будет уменьшено до нуля.

Безопасность и управление доступом

KEDA поддерживает аутентификацию для подключения к внешним источникам событий. Для этого используются стандартные механизмы Kubernetes: Secrets, ConfigMaps, а также облачные провайдеры (AWS IAM, Azure Managed Identity, Google Cloud Service Accounts). Начиная с версии 2.0, KEDA поддерживает ролевую модель (RBAC) для ограничения доступа к ресурсам ScaledObject и ScaledJob.

Связь с другими проектами

KEDA тесно интегрируется с экосистемой Kubernetes и CNCF. Он часто используется совместно с:

  • Prometheus — для получения метрик из мониторинговой системы.
  • Knative — для бессерверных (serverless) рабочих нагрузок на Kubernetes.
  • Apache Kafka — для масштабирования потребителей на основе лага.
  • Argo Workflows — для запуска заданий по событиям.

Интересные факты

  • Название KEDA происходит от слов «Kubernetes Event-Driven Autoscaling».
  • Проект является одним из самых популярных в категории автоматического масштабирования на Kubernetes: на GitHub он имеет более 8 тысяч звёзд (на начало 2025 года).
  • KEDA поддерживает не только масштабирование до нуля, но и «масштабирование от нуля» (scale from zero), то есть может запускать приложение, которое до этого не имело ни одной реплики.
  • В 2022 году KEDA был признан одним из лучших проектов CNCF по версии сообщества.

Источники

  • Официальная документация проекта KEDA (keda.sh)
  • Репозиторий проекта на GitHub (github.com/kedacore/keda)
  • Документация Cloud Native Computing Foundation (CNCF) по KEDA
  • Статьи в блогах Microsoft и Red Hat о событийно-ориентированном масштабировании
  • Материалы конференций KubeCon и CloudNativeCon

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы