Cluster Autoscaler / Karpenter
Тема дорожной карты · Kubernetes
Cluster Autoscaler — компонент Kubernetes, автоматически регулирующий количество рабочих узлов в кластере: добавляет узлы, когда Pod'ы не могут быть запланированы из-за нехватки ресурсов, и удаляет слабо загруженные узлы для снижения затрат на инфраструктуру. Он интегрируется с API облачных провайдеров (AWS Auto Scaling Groups, GCP Managed Instance Groups, Azure VMSS) и настраивается с помощью флагов --node-group-auto-discovery или явного указания --nodes=min:max:group в Deployment cluster-autoscaler. Karpenter — более новая, нативная для AWS альтернатива, которая подготавливает EC2-инстансы подходящего размера за считанные секунды, напрямую сопоставляя пользовательские ресурсы NodePool и EC2NodeClass с запросами ресурсов ожидающих Pod'ов, полностью обходя абстракцию групп узлов. Cluster Autoscaler и Karpenter совместно работают с HPA и VPA, обеспечивая полностью эластичный кластер Kubernetes, масштабирующий как Pod'ы, так и узлы в ответ на реальную нагрузку.
Как это работает
Cluster Autoscaler / Karpenter покрывает day-2 работу эксплуатации Kubernetes-кластера: обновления, node maintenance, capacity planning, backup и DR, оптимизация стоимости, multi-tenancy изоляция. Обновления следуют графику deprecation Kubernetes (один minor каждые 4 месяца); node maintenance использует cordon + drain; backups через Velero или CSI snapshots. DR требует регулярных тренировок — не только документации.
Когда применять
Установите Cluster Autoscaler / Karpenter практики до того, как кластер станет критичным для выручки. Запланируйте первую DR-тренировку в течение 30 дней после go-live; задокументируйте процедуру обновления до того, как первая версия станет EOL; настройте cost-дашборды (Kubecost, OpenCost) до того, как счёт станет сюрпризом. Operations-долг копится тихо — гасите его по каденции, не в режиме паники.
Типичные ошибки
Ловушки cluster operations: пропуск minor-обновлений до принуждения (3+ версий позади = кошмар обновления); cluster-wide cluster-admin tokens, которые никто не ротирует; нет задокументированного runbook на случай "control plane умер" (реальная возможность на self-managed кластерах); cost-сюрпризы (idle GPU-ноды, over-provisioned requests, orphan PVCs). Тренируйте incident response на non-production кластере ежемесячно.