Настройка Kubernetes Cluster Autoscaler (Node Autoscaling)
После развёртывания Kubernetes-кластера с HPA вы замечаете, что поды масштабируются, но новые ноды не добавляются. Логи Cluster Autoscaler молчат, поды висят в состоянии Pending. Типичная ситуация: на одном из проектов клиент потерял 3 часа продакшн-доступности из-за неправильной конфигурации CA. Мы решаем такие проблемы на регулярной основе — за 5 лет работы с k8s на 30+ проектах. Cluster Autoscaler (CA) автоматизирует масштабирование нод: он добавляет вычислительные ресурсы, когда поды не могут быть запланированы из-за нехватки CPU или памяти, и удаляет ноды при снижении нагрузки. Но его поведение сильно зависит от настроек облачного провайдера и политик планировщика.
CA работает на уровне нод: добавляет и удаляет ноды в зависимости от наличия подов в состоянии Pending из-за нехватки ресурсов. В связке с HPA или KEDA это полный цикл: нагрузка растёт → HPA добавляет поды → поды не помещаются → CA добавляет ноду → поды запускаются. Однако в реальности процесс часто ломается из-за тонких настроек.
Почему новые ноды не появляются?
Самый частый сценарий: CA настроен, поды в Pending, но ноды не добавляются. Команда kubectl describe pod <pending-pod> покажет точную причину. Типичные причины:
-
Pod не unschedulable из-за ресурсов, а из-за affinity/taint. Например, если под использует
nodeSelector: gpu: "true", а в пуле нет GPU-инстансов, CA не сможет помочь — он создаёт ноды только из существующих node groups. - PodDisruptionBudget (PDB) блокирует скейлинг вниз. CA пытается удалить ноду, переселив поды, но PDB запрещает эвакуацию. Нода остаётся, экономия ресурсов не происходит.
-
Scale-down blocked by system pods. CA не удаляет ноды с подами без PDB, standalone pods, подами с аннотацией
cluster-autoscaler.kubernetes.io/safe-to-evict: "false"илиhostPathvolumes. Для диагностики используйтеkubectl describe node <node> | grep -A5 "Annotations".
Пример диагностики
kubectl get pods --field-selector=status.phase=Pending kubectl describe pod pending-pod-name Обратите внимание на события и условия. Если причина — 0/1 nodes are available: 1 Insufficient cpu, то CA должен сработать.
Как Cluster Autoscaler взаимодействует с HPA?
HPA увеличивает количество подов при росте нагрузки. Когда ресурсы текущих нод исчерпаны, новые поды переходят в состояние Pending, и CA добавляет ноду. Важно настроить задержки: --scale-down-delay-after-add=10m не даёт CA удалить ноду сразу после появления, а --scale-down-unneeded-time=10m — время простоя перед удалением. Это предотвращает флуктуации при пиковых нагрузках. По нашим данным, правильные задержки снижают количество лишних скейлингов на 40%.
Конфигурация для облачных провайдеров
AWS (EKS)
command:
- ./cluster-autoscaler
- --v=4
- --stderrthreshold=info
- --cloud-provider=aws
- --skip-nodes-with-local-storage=false
- --expander=least-waste
- --node-group-auto-discovery=asg:tag=k8s.io/cluster-autoscaler/enabled,k8s.io/cluster-autoscaler/my-cluster
- --balance-similar-node-groups
- --scale-down-delay-after-add=10m
- --scale-down-unneeded-time=10m--expander=least-waste выбирает node group, которая наиболее эффективно использует ресурсы новой ноды. Альтернативы: random, most-pods, priority (по явно заданным приоритетам node groups).
--balance-similar-node-groups балансирует ноды между похожими группами — важно для multi-AZ деплоя, чтобы ноды распределялись между зонами доступности.
GKE (Standard)
На GKE Cluster Autoscaler управляется через gcloud при создании node pool:
gcloud container node-pools create general \
--cluster=my-cluster \
--enable-autoscaling \
--min-nodes=1 \
--max-nodes=20 \
--machine-type=n2-standard-4
На bare metal или kubeadm-кластерах CA работает только если есть API для управления нодами — например, через cloud-controller-manager или кастомный провайдер.
Когда стоит выбрать Karpenter вместо Cluster Autoscaler?
На AWS Karpenter — более гибкое решение. Он не привязан к заранее созданным Auto Scaling Groups: сам выбирает тип инстанса на основе потребностей подов и запрашивает его через EC2 API. Разница: CA добавляет ноду из фиксированного node pool с конкретным instance type, а Karpenter смотрит на requests всех pending подов и выбирает самый дешёвый подходящий тип — может быть m5.large, может быть c6i.2xlarge. Spot instances поддерживаются нативно.
NodePool Karpenter:
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: general
spec:
template:
spec:
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ["spot", "on-demand"]
- key: kubernetes.io/arch
operator: In
values: ["amd64"]
limits:
cpu: 1000
disruption:
consolidationPolicy: WhenUnderutilized
consolidateAfter: 1m
consolidateAfter: 1m — Karpenter агрессивно консолидирует: если ноды недогружены, он переселяет поды и убирает лишние. Это снижает расходы на AWS на 30-50% по нашим оценкам. Karpenter быстрее реагирует на изменения: консолидация происходит за минуту, а не за 10 минут как у CA.
Сравнение Cluster Autoscaler и Karpenter
| Параметр | Cluster Autoscaler | Karpenter |
|---|---|---|
| Типы инстансов | Фиксированные из ASG | Динамический выбор |
| Spot instances | Через ASG | Нативная поддержка |
| Консолидация | Базовая | Агрессивная (1 min) |
| Конфигурация | Флаги CA | Custom Resource |
| Провайдеры | AWS, GCP, Azure | AWS (пока) |
Типовые параметры задержек CA
| Параметр | Значение по умолчанию | Рекомендуемое | Описание |
|---|---|---|---|
scale-down-delay-after-add |
10m | 10m | Задержка после добавления ноды перед возможным удалением |
scale-down-delay-after-delete |
0s | 10s | Задержка после удаления ноды |
scale-down-delay-after-failure |
3m | 3m | Задержка после неудачного скейлинга |
scale-down-unneeded-time |
10m | 5-10m | Время простоя ноды перед удалением |
Как провести диагностику скейлинга?
- Проверьте статус CA:
kubectl get pods -n kube-system | grep cluster-autoscaler. - Посмотрите логи:
kubectl logs -n kube-system deployment/cluster-autoscaler --tail=50. - Убедитесь, что metrics-server работает:
kubectl top nodes. - Проверьте, что поды имеют requests: CA не масштабирует поды без requests.
- Используйте
kubectl describe pod <pending-pod>для анализа событий.
Что входит в работу по настройке автокейлинга
- Аудит текущей конфигурации кластера и нагрузки.
- Выбор стратегии: CA или Karpenter.
- Настройка CA с правильными expander, задержками, балансировкой.
- Конфигурация PDB для системных подов.
- Интеграция с мониторингом (Prometheus+Grafana).
- Документация по эксплуатации и runbook.
Сроки и стоимость
Настройка CA для одного облачного провайдера с базовыми параметрами — от 1 дня. Полная настройка с multi-AZ, PDB, мониторингом — от 1 до 3 дней. Миграция на Karpenter — от 2 дней. Стоимость рассчитывается индивидуально после аудита. Обращаясь к нам, вы получаете гарантию корректной работы Cluster Autoscaler в боевых условиях. Свяжитесь с нами для оценки вашего проекта — мы поможем оптимизировать расходы на облачные ресурсы.
Опыт наших инженеров — 5+ лет работы с Kubernetes, более 30 успешных проектов по автоматизации инфраструктуры. Грамотная настройка CA экономит от $500 до $3,000 ежемесячно в зависимости от масштаба.
Мониторинг
Метрики CA в Prometheus: cluster_autoscaler_nodes_count, cluster_autoscaler_unschedulable_pods_count, cluster_autoscaler_last_activity. Алерт на cluster_autoscaler_errors_total > 0 — сигнал, что CA не может скейлить из-за ошибок API облачного провайдера. Настройте дашборд в Grafana для визуализации трендов.
Источник: официальная документация Cluster Autoscaler на GitHub
