Введение
Автоматическое масштабирование подов в Kubernetes — одна из главных «киллер-фич» оркестратора. Однако стандартный Horizontal Pod Autoscaler (HPA) ориентирован на метрики CPU и памяти, чего часто недостаточно для реальных сценариев. Oracle в своём новом блоге «Scale Kubernetes Smarter with KEDA, OKE, and OCI Queue» предлагает альтернативный подход — событийно-ориентированное масштабирование с помощью KEDA (Kubernetes Event-Driven Autoscaling), интегрированного с Oracle Kubernetes Engine (OKE) и облачной очередью OCI Queue.
Суть новости
В статье Oracle рассматривает, как объединить три технологии для создания эластичной инфраструктуры, которая реагирует не на прогрев CPU, а на реальную рабочую нагрузку — сообщения в очереди. OCI Queue выступает в роли ScaledObject — источника событий, который KEDA мониторит в реальном времени. Когда количество сообщений в очереди превышает порог, KEDA динамически увеличивает количество реплик пода (рабочего процесса). При снижении нагрузки — автоматически уменьшает. Всё это происходит в управляемом кластере OKE, без необходимости вручную настраивать HPA или писать кастомные метрики.
Технические детали
KEDA как основа
KEDA — это open-source проект (incubating CNCF), который расширяет HPA. Он добавляет два ключевых ресурса: ScaledObject и TriggerAuthentication. ScaledObject определяет, какой деплоймент масштабировать, с какой минимальной/максимальной границей реплик и на основе какого триггера. В случае Oracle используется триггер oci-queue, который подключается к OCI Queue через API с аутентификацией (API-ключ или инстанс-принципал).
OKE — управляемый Kubernetes
Oracle Kubernetes Engine предоставляет managed control plane, автоматические обновления и интеграцию с сетью OCI. В статье отмечается, что OKE из коробки поддерживает Cluster Autoscaler для узлов, но для подов рекомендуется именно KEDA, так как он даёт более точное событийное масштабирование. Кластер настраивается с помощью kubectl и стандартных манифестов.
OCI Queue как источник событий
OCI Queue — это fully-managed очередь сообщений. В отличие от Kafka или RabbitMQ, она не требует администрирования брокеров. Сообщения хранятся в очереди заданной ёмкости и могут быть считаны приложением. KEDA с помощью scalers (встроенный для OCI Queue) опрашивает очередь с настраиваемым интервалом (по умолчанию 10 секунд). Когда количество сообщений превышает заданный порог (например, 1), KEDA отправляет метрику в HPA, и число реплик увеличивается.
Пример конфигурации ScaledObject:
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: queue-scaler
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: worker
pollingInterval: 10
cooldownPeriod: 60
minReplicaCount: 1
maxReplicaCount: 20
triggers:
- type: oci-queue
metadata:
queueId: ocid1.queue...
queueConnectionString: "..."
authenticationRef:
name: oci-queue-auth
При такой конфигурации при появлении сообщений реплики разворачиваются в считанные секунды. После опустошения очереди через 60 секунд (cooldown) они свернутся до минимума.
Что это значит для админов и владельцев инфраструктуры
Экономия ресурсов и стоимости
Стандартный HPA, работающий по CPU, часто держит избыточные реплики «на всякий случай». KEDA с OCI Queue масштабирует поды точно под нагрузку: поды создаются только когда есть работа (сообщения), и удаляются при её отсутствии. Это особенно актуально для batch-обработчиков, ETL-пайплайнов, сервисов отправки email или генерации отчетов.
Упрощение архитектуры
Раньше для событийного масштабирования приходилось комбинировать Prometheus + custom metrics API, писать адаптеры. KEDA берет эту работу на себя — достаточно всего нескольких манифестов. OCI Queue при этом не требует развертывания брокера, всё управляется облаком.
Совместимость и переносимость
KEDA поддерживает десятки scalers (AWS SQS, GCP Pub/Sub, RabbitMQ, Kafka и т.д.). Если вы решите сменить провайдера, нужно будет только поменять тип триггера и настройки аутентификации. OCI Queue, как и другие сервисы OCI, легко встраивается в экосистему Oracle, но при желании может быть заменён.
Практические выводы
- Для тех, кто уже использует OKE — добавление KEDA с OCI Queue не потребует переписывания приложения. Достаточно добавить ScaledObject и настроить очередь. Приложение должно уметь обрабатывать сообщения из OCI Queue (SDK предоставляется).
- Для тех, кто планирует миграцию — если у вас есть batch-задачи, которые сейчас работают на cron или всегда включены, попробуйте перевести их на событийную модель. Вы увидите снижение затрат на compute за счёт отсутствия холостых реплик.
- Мониторинг — используйте встроенный KEDA Operator metrics вместе с Prometheus, чтобы видеть текущее количество реплик и глубину очереди. Oracle также рекомендует настроить логи в OCI Logging Analytics.
- Безопасность — используйте инстанс-принципалы (instance principals) для аутентификации KEDA к OCI Queue, чтобы не хранить ключи в манифестах. TriggerAuthentication можно связать с Vault.
Заключение
Сочетание KEDA, OKE и OCI Queue — это элегантное решение для event-driven autoscaling в Kubernetes. Оно позволяет отвязать масштабирование от системных метрик и перейти к бизнес-логике: «сколько сообщений — столько и подов». Oracle уже показала работающий пример, и теперь сообщество может его повторить. Рекомендуем изучить официальную документацию KEDA для OCI Queue и протестировать на тестовом кластере в OCI (бесплатные ресурсы доступны в Always Free Tier).