Автомасштабирование в Kubernetes: HPA, VPA и Cluster Autoscaler
Продвинутое4 минРедакция Innovialabs
Коротко
HPA меняет число подов, VPA — запросы CPU и памяти каждого пода, Cluster Autoscaler добавляет и убирает ноды; сочетайте HPA с Cluster Autoscaler и не давайте HPA и VPA работать по одной и той же метрике ресурса.
Три автоскейлера — три разные задачи
Kubernetes масштабируется на трёх уровнях, и каждый инструмент отвечает на свой вопрос:
| Инструмент | Что меняет | На что реагирует | Типичное применение |
|---|---|---|---|
| HPA (Horizontal Pod Autoscaler) | Число реплик подов | CPU, память, кастомные или внешние метрики | Stateless веб-сервисы и воркеры |
| VPA (Vertical Pod Autoscaler) | Запросы CPU и памяти подов | Фактическое потребление ресурсов во времени | Подбор requests, сервисы, которые плохо масштабируются вширь |
| Cluster Autoscaler | Число нод | Поды в Pending, недогруженные ноды | Место для новых подов, экономия |
HPA встроен в Kubernetes. VPA и Cluster Autoscaler — отдельные компоненты, их устанавливают отдельно (облачные провайдеры часто предлагают автоскейлер нод как опцию; популярная альтернатива для выделения нод — Karpenter).
Как работает HPA
С регулярным интервалом HPA читает метрику, сравнивает её с целевым значением и считает нужное число реплик, примерно так:
desiredReplicas = ceil(currentReplicas × currentValue / targetValue)
Если 4 пода в среднем загружены на 90% CPU при цели 60%, HPA захочет 6. Небольшой допуск не даёт ему реагировать на мелкие отклонения.
Два условия легко упустить:
- Для метрик CPU и памяти должен быть установлен metrics-server.
- У контейнеров должны быть заданы CPU requests. Утилизация считается в процентах от request; без него HPA ничего не посчитает.
Настройка HPA по CPU и кастомной метрике
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: api
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: api
minReplicas: 3
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60
- type: Pods
pods:
metric:
name: http_requests_per_second
target:
type: AverageValue
averageValue: "100"
behavior:
scaleUp:
stabilizationWindowSeconds: 0
policies:
- type: Pods
value: 4
periodSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 50
periodSeconds: 60
При нескольких метриках HPA считает число реплик для каждой и выбирает наибольшее. Значения здесь условные — подбирайте их по результатам нагрузочных тестов.
Кастомные метрики вроде запросов в секунду или длины очереди по умолчанию недоступны. Нужен адаптер, который отдаёт их в metrics API Kubernetes, например Prometheus Adapter, или KEDA, которая умеет масштабировать по длине очереди, расписанию cron и множеству внешних источников. Для воркеров очередей глубина очереди обычно лучший сигнал, чем CPU.
Как работает VPA
У VPA три части: recommender следит за потреблением, updater может вытеснять поды с сильно неверными requests, admission controller проставляет новые requests при создании подов. Режимы обновления — от Off (только рекомендации) до режимов, которые применяют их автоматически.
Безопасный старт — режим Off: читайте рекомендации и правьте requests вручную. Автоматические режимы могут перезапускать поды, поэтому защитите сервисы через PodDisruptionBudget.
Как работает Cluster Autoscaler
Cluster Autoscaler не смотрит на загрузку CPU. Он реагирует на планирование:
- Если поды висят в Pending, потому что ни на одной ноде не хватает свободных запрошенных ресурсов, он добавляет ноду из группы.
- Если нода долго недогружена и её поды можно перенести, он сливает её и удаляет.
Поэтому точные requests так важны: именно их считают и планировщик, и автоскейлер. Поды без requests, с локальным хранилищем или со строгими PodDisruptionBudget могут мешать уменьшению кластера.
Как избежать дёрганий и конфликтов
- Не запускайте HPA и VPA по одной метрике CPU или памяти для одной нагрузки. VPA поднимает requests, утилизация падает, HPA убирает поды, нагрузка на под растёт — и цикл повторяется. Если нужны оба, пусть HPA работает по кастомной метрике, а VPA — по ресурсам, либо держите VPA в режиме
Off. - Используйте окна стабилизации, особенно для уменьшения, чтобы короткие провалы не убирали поды, которые понадобятся через минуту.
- Ограничьте скорость изменений политиками
behavior. - Учитывайте время старта. Если поды долго становятся готовыми, новые реплики приходят поздно, и HPA продолжает добавлять ещё. Используйте readiness- и startup-пробы и держите образы лёгкими.
- Задайте разумный minReplicas, чтобы был запас на резкий всплеск, пока поднимаются новые поды и ноды.
- Проверяйте всю цепочку: HPA может запросить 20 подов, но если кластер не может добавить ноды или база не принимает больше соединений, масштабирование лишь переносит узкое место.