Налаштування 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
