Kubernetes autoscaling 2026: HPA vs VPA vs KEDA — что выбрать и как не сломать прод

Обзоры
26 янв, 2026
Время на чтение: ~15 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Зачем в 2026 разбираться в HPA, VPA и KEDA

Автоскейлинг в Kubernetes давно не сводится к «добавим replicas при 80% CPU». В проде он закрывает три разные задачи: (1) сколько подов держать прямо сейчас, (2) какого «размера» должен быть под (CPU/RAM requests), (3) как реагировать на события вне кластера (очереди, лаги, расписания, внешние метрики).

За эти задачи отвечают три инструмента: HPA, VPA и KEDA. Ошибка — воспринимать их как взаимоисключающие. В 2026 чаще выигрывают связки, но только если заранее определить границы ответственности.

Ниже — практическая модель выбора, типовые грабли (requests, флаппинг, прогрев), и схемы внедрения, которые не ломают продакшен.

Быстрая модель: что именно масштабируем

HPA (Horizontal Pod Autoscaler) — меняет количество реплик (replicas) у Deployment/StatefulSet и т.п.
VPA (Vertical Pod Autoscaler) — подбирает requests/limits контейнеров (CPU/RAM), часто через пересоздание подов (зависит от режима).
KEDA — event-driven autoscaling: поднимает/опускает реплики по сигналам из внешних систем (очереди, lag, cron, Prometheus-запросы) и обычно управляет HPA «под капотом».

Удобная формула: HPA отвечает за «сколько подов», VPA — за «какие поды по ресурсам», KEDA — за «какой сигнал считать нагрузкой и как реагировать на внешний мир».

Схема: HPA, VPA и KEDA и потоки метрик в Kubernetes

HPA в 2026: сильные стороны и ограничения

HPA — базовый механизм kubernetes autoscaling. Он периодически читает метрики, сравнивает их с целевыми значениями и меняет replicas. На практике результат определяют четыре вещи: источник метрик, качество requests, поведение при «скачках» и задержка реакции.

Какие метрики поддерживает HPA

Resource metrics: CPU/Memory — обычно через metrics-server.
Custom metrics: прикладные/инфраструктурные метрики (RPS, in-flight, queue depth) — через адаптеры custom/external metrics.
External metrics: метрики вне кластера — при наличии провайдера.

В 2026 «только CPU» редко достаточно: для I/O-bound API, воркеров и систем с очередями CPU может быть низким, пока SLO уже горит.

Главный подводный камень HPA — качество requests

HPA по CPU ориентируется не на «процент от лимита», а на отношение фактического потребления к requests.cpu. Отсюда типовые сценарии:

requests завышены — HPA поздно масштабируется, потому что «процент к requests» выглядит нормальным.
requests занижены — HPA масштабируется слишком агрессивно, раздувает реплики, создаёт лишнее планирование и давление на кластер.

Для памяти HPA часто менее предсказуем: потребление растёт ступенчато, а реакция может оказаться либо слишком поздней, либо «гармошкой». Для memory-sensitive сервисов чаще выигрывают прикладные сигналы или VPA.

Anti-flapping: как не устроить «гармошку»

Флаппинг (вверх-вниз каждые пару минут) обычно появляется из-за шумной метрики, кешей и неверного времени стабилизации. Для прода в HPA v2 поведение (behavior) стоит считать обязательным: ограничивайте скорость scale up/down и задавайте окна стабилизации.

Практическое правило: scale up делайте быстрее, scale down — заметно медленнее. Иначе вы будете регулярно «съедать» холодные кеши и ловить волны латентности.

Минимальный пример HPA v2 с behavior

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 30
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 60
      selectPolicy: Max
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 20
        periodSeconds: 60
      selectPolicy: Max

Где HPA не подходит

Когда нужно стабильное scale-to-zero и быстрый подъём «по событию», а не по ресурсу.
Когда нагрузка не коррелирует с CPU/RAM, а нормальные custom metrics недоступны или слишком дороги в сопровождении.
Когда воркеры должны масштабироваться по backlog/lag, а не по загрузке контейнера.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

VPA в 2026: автоподбор requests без гадания

VPA закрывает боль «какие requests выставить», чтобы одновременно не ловить throttling/evictions/OOM и не держать постоянный overprovisioning. Он собирает историю потребления CPU/RAM и выдаёт рекомендации (target/lowerBound/upperBound), а в некоторых режимах применяет их автоматически.

Режимы VPA и что выбирать на старте

Off — только рекомендации. Лучший старт почти для любого кластера.
Initial — выставляет requests при создании пода, но не трогает уже запущенные.
Auto — применяет изменения через пересоздание подов (вертикальное масштабирование почти всегда требует рестарта).

Рабочий сценарий: включаете VPA в Off или Initial, собираете статистику 1–2 недели (или хотя бы один полный цикл нагрузки), затем точечно и очень осторожно пробуете Auto на некритичных компонентах.

Где VPA приносит максимальную пользу

Сервисы с «плавающей» памятью (данные, кеши, GC), где ручные requests.memory постоянно мимо.
Воркеры и джобы, где размер задач сильно различается.
Команды, которым нужна дисциплина requests без вечных споров «256Mi или 512Mi».

Ограничения VPA, которые реально влияют на прод

Рестарты в Auto: без PDB, достаточных реплик и корректного readiness это легко превращается в деградацию или даунтайм.
Stateful-нагрузка: для StatefulSet продумайте порядок обновления и влияние пересозданий на кворум/репликацию/кеш.
Конфликт с HPA по CPU: VPA меняет requests.cpu, а HPA по CPU масштабируется относительно requests. После пересчёта requests HPA может начать вести себя иначе.

Практичный взгляд на VPA: это инструмент «навести порядок в requests». Экономия и стабильность — следствие адекватных requests и снижения overprovisioning, а не магия.

KEDA в 2026: event-driven autoscaling без самописных костылей

KEDA полезна там, где «истинная нагрузка» живёт не в CPU/RAM. KEDA подключает источники событий (scalers) и по ним масштабирует workload, чаще всего создавая и управляя HPA.

Что KEDA закрывает лучше всего

Очереди и стримы: масштабирование воркеров по backlog/lag — самый понятный и предсказуемый кейс.
Prometheus-метрики: RPS, ошибки, saturation, in-flight — если у вас зрелая наблюдаемость и правильные запросы.
Cron-нагрузки: поднимать реплики заранее перед пиками.
Scale-to-zero: держать 0 реплик при отсутствии событий и поднимать при появлении работы.

Где KEDA может удивить

Холодный старт: scale-to-zero экономит ресурсы, но добавляет задержку (image pull, init, JIT/кеши, прогрев соединений).
Надёжность метрик: если источник метрик недоступен или запрос «шумный», скейлинг становится нестабильным.
Порог — это архитектура: «сколько сообщений на 1 реплику» или «какой lag допустим» — это про SLO и производительность воркера, а не только YAML.

Если вы выносите monitoring и метрики в отдельную инфраструктуру, часто удобнее держать её на отдельном VDS: проще управлять дисками, retention и ресурсами Prometheus/Thanos, не конкурируя с прод-нагрузкой приложений.

Пример event-driven autoscaling: очередь, backlog и рост числа реплик воркеров

Метрики: metrics-server, custom metrics и «куда утекает правда»

Любой autoscaling упирается в метрики и их качество. Типовая архитектура (и типовые проблемы) выглядят так:

metrics-server даёт resource metrics для HPA/VPA (CPU/RAM), но не предназначен для долгого хранения и продвинутой аналитики.
Prometheus (или аналог) хранит историю, позволяет агрегировать и строить запросы для custom/external metrics.
Metrics adapter превращает метрики из мониторинга в API, понятный HPA.
KEDA может брать данные напрямую из внешних источников (включая Prometheus) и транслировать их в поведение HPA.

Правило, которое экономит деньги и нервы: если вы не уверены в метрике, не используйте её для scaling. Сначала проверьте, что она стабильна, не пропадает при сбоях, правильно агрегируется и действительно коррелирует с перегрузкой.

По наблюдаемости автоскейлинга полезно отдельно настроить алерты на доступность «источника правды» (например, blackbox-проверки endpoints мониторинга). См. также: blackbox-проверки HTTP/TCP/ICMP для мониторинга.

Как выбрать: матрица решений для продакшена

Сценарий 1: stateless HTTP API, нагрузка коррелирует с CPU

Обычно достаточно HPA по CPU плюс behavior, чтобы избежать флаппинга. Если requests выставлены «на глаз» — подключайте VPA в режиме Off/Initial, соберите рекомендации и приведите requests к реальности.

Сценарий 2: I/O-bound API, CPU низкий, а latency растёт

HPA по CPU может молчать, пока пользователи уже страдают. Нужны custom metrics: RPS на pod, in-flight requests, saturation пула соединений, длина внутренней очереди. Технически это либо HPA с custom metrics, либо KEDA через Prometheus scaler (если вы уже опираетесь на Prometheus как на источник метрик).

Сценарий 3: воркеры очереди

Стандарт — KEDA по backlog/lag. HPA по CPU для воркеров часто вторичен и может вводить в заблуждение: воркер может быть CPU-лёгким, но очередь при этом растёт.

Сценарий 4: память — главный риск (OOM/evictions)

VPA обычно даёт максимум пользы, потому что память сложнее всего «угадать» requests’ами. Начните с Off, затем аккуратно применяйте Initial/Auto, параллельно контролируя OOM и eviction-события.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Совместное использование: что можно, что нельзя и где нужна осторожность

HPA + VPA

Совместное использование возможно, но требует дисциплины и наблюдаемости:

Если HPA масштабируется по CPU, а VPA активно меняет requests.cpu, у вас меняется «линейка измерения» для HPA. Это легко приводит к неожиданным скачкам replicas.
Частая практика: VPA применять для памяти (и/или для выдачи рекомендаций), а HPA — для количества реплик по CPU или прикладной метрике, контролируя изменения requests.
Начинайте с VPA Off и внедряйте изменения постепенно.

HPA + KEDA

KEDA часто и есть «HPA с внешними сигналами». Рабочая схема: KEDA отвечает за масштабирование по событиям, а внутри pod вы настраиваете concurrency/пулы/таймауты так, чтобы производительность одной реплики была предсказуемой.

VPA + KEDA

Хорошая комбинация для воркеров: KEDA решает «сколько воркеров», VPA — «сколько CPU/RAM нужно воркеру», особенно если размер задач плавает.

Типовые ошибки autoscaling, которые дорого стоят

Нет requests или они случайные: HPA по CPU становится бессмысленным, QoS ухудшается, планировщик распределяет нагрузку хуже.
Нет PDB и запаса реплик: любые пересоздания (включая VPA Auto и деплои) быстрее превращаются в простой.
Скейлим по шумной метрике: HPA начинает дёргать replicas, вы получаете каскадные эффекты (кеши, БД, лимиты внешних API).
Игнорируем время прогрева: новая реплика не сразу начинает приносить пользу. Без учёта warm-up скейлинг реагирует «слишком поздно».
Нет пределов: отсутствие понятных min/max и ограничений на scale-up может раздувать кластер и перегружать зависимости.

Практический чек-лист внедрения (без фанатизма)

Приведите в порядок requests/limits: хотя бы базово, иначе метрики будут интерпретироваться неверно.
Проверьте доступность resource metrics: убедитесь, что метрики CPU/RAM не «проваливаются» в моменты нагрузки.
Выберите сигнал scaling: CPU, backlog, RPS, saturation — тот, который отражает узкое место.
Настройте поведение: окна стабилизации и скорость scale down, чтобы избежать флаппинга.
Прогоните нагрузку: замерьте, через сколько секунд новая реплика начинает помогать, и как быстро нужно реагировать.
Добавьте наблюдаемость: графики replicas, метрик, события HPA/VPA, а также saturation БД/кеша/внешних API.

Итоги: что выбрать в 2026

HPA — базовый выбор для stateless сервисов, если CPU коррелирует с нагрузкой и requests настроены.
VPA — лучший способ перестать «гадать» с requests и стабилизировать потребление ресурсов (особенно по памяти).
KEDA — лучший выбор для очередей/стримов и event-driven scaling, когда CPU — плохой индикатор.

Сильный autoscaling — это не один компонент, а комбинация правильных метрик, реалистичных requests, ограничений поведения и понимания времени прогрева. Начните с простого, измеряйте, и только потом усложняйте.

Поделиться статьей