Автоскейлинг и HPA

Черная пятница: трафик Pinterest вырастает в 8x за 10 минут. До автоскейлинга команда вручную добавляла серверы заранее (дорого) и убирала после (медленно). С HPA + Karpenter: кластер автоматически масштабируется от 200 до 1600 нод за 15 минут и возвращается обратно. Стоимость инфраструктуры соответствует реальному трафику, а не пиковым ожиданиям.

• **Delivery Hero** использует KEDA для масштабирования order-processing воркеров: в пиковое время (ужин) 500 воркеров, в 3 ночи - 0 подов и 0 оплаты за idle инстансы
• **Spotify** мигрировал с Cluster Autoscaler на Karpenter - скорость добавления нод ускорилась с 3-4 минут до 45 секунд при spike нагрузки после выхода нового релиза артиста
• **Shopify** настроил VPA для анализа resource requests 3000+ микросервисов - обнаружено что 60% сервисов были пере-провизированы в 3-5x; экономия $2M/год на облачных расходах

HPA (Horizontal Pod Autoscaler)

HPA автоматически изменяет количество реплик Deployment на основе метрик. По умолчанию - CPU utilization, но поддерживает любые метрики через Metrics API: RPS, queue depth, latency. Алгоритм: `желаемые реплики = ceil(текущие реплики * (текущая метрика / целевая метрика))`. Cooldown периоды: scale-up 0-180s, scale-down 5 минут.

Критическая настройка: resource requests в Pod должны быть точно выставлены. HPA смотрит на CPU utilization как % от requests, не от capacity ноды. Если requests занижены - HPA не запустит скейлинг вовремя (CPU 80% от requests при реальном 10% capacity). Рекомендуют: requests = p50 latency нагрузка, limits = 2x requests.

VPA (Vertical Pod Autoscaler)

VPA автоматически рекомендует и устанавливает правильные resource requests/limits для подов на основе исторического потребления. Режимы: Off (только рекомендации), Initial (устанавливает при создании), Recreation (пересоздаёт поды с новыми значениями), Auto (то же что Recreation). VPA и HPA не должны управлять одним ресурсом одновременно.

VPA решает проблему под-/пере-провизионирования requests. Новый микросервис - инженер ставит CPU: 100m/500m наугад. VPA через неделю работы скажет: 'рекомендую 45m/250m' основываясь на p95 потребления. Это снижает costs (меньше зарезервировано) и улучшает scheduling (нода вмещает больше подов). Используют VPA в режиме Off для рекомендаций, ручной корректировки и мониторинга.

Cluster Autoscaler

Cluster Autoscaler (CA) масштабирует ноды кластера: добавляет ноды когда поды не помещаются (Pending из-за insufficient resources), удаляет незагруженные ноды (<50% utilization). Интегрируется с AWS ASG, GCP MIG, Azure VMSS. Дополнение - Karpenter (AWS): умнее CA, выбирает оптимальный instance type для конкретных Pod requirements.

Karpenter vs Cluster Autoscaler: CA работает с pre-configured node groups (fixed instance type), Karpenter динамически выбирает instance type под Pod requirements (CPU, GPU, memory, spot preference). Karpenter быстрее (30-60s vs 2-5min), умнее с Spot и дешевле на 40-60% за счёт bin packing. AWS рекомендует Karpenter для EKS с 2022 года.

KEDA (Event-Driven Autoscaling)

KEDA (Kubernetes Event-Driven Autoscaling) масштабирует Deployment на основе внешних событий: длина очереди SQS, Kafka lag, RPS в Prometheus, количество сообщений в RabbitMQ. Может масштабировать до 0 реплик когда очередь пуста (HPA не умеет масштабировать до 0). Идеален для batch обработки и consumer-воркеров.

Scalers в KEDA: 60+ встроенных источников. Популярные: aws-sqs-queue (по глубине очереди), kafka (по consumer group lag), prometheus (по любой метрике), azure-service-bus, rabbitmq. KEDA работает поверх HPA - создаёт ScaledObject который управляет HPA через Kubernetes Metrics API. Это означает полную совместимость с существующими инструментами.

Ключевые идеи

• **HPA** масштабирует поды по CPU/custom метрикам; точные resource requests - основа корректной работы; cooldown период защищает от flapping
• **VPA** рекомендует правильные requests/limits на основе исторического потребления; используй в режиме Off для анализа, не Auto совместно с HPA
• **Karpenter + KEDA** - следующий уровень: Karpenter умно добавляет ноды (30s, оптимальный instance type); KEDA масштабирует до 0 по внешним событиям (SQS, Kafka)

Связанные темы

Автоскейлинг - часть более широкой стратегии cost optimization и reliability:

• K8s: продвинутые паттерны — HPA, VPA и Karpenter - extensions K8s API; работают с теми же Deployment/StatefulSet ресурсами
• Serverless: Lambda, Cloud Functions — Lambda автоматически масштабируется до 1000 concurrent без настройки; K8s автоскейлинг - явная конфигурация того же поведения

Вопросы для размышления

• Если сервис обрабатывает batch задачи из SQS очереди ночью - HPA по CPU или KEDA по queue depth? Почему?
• При spike нагрузки поды масштабируются быстро но ноды добавляются медленно (2-3 мин). Как минимизировать этот gap?
• VPA рекомендует снизить CPU requests с 500m до 120m для сервиса. Каковы риски принятия этой рекомендации?

Связанные уроки

• alg-14-dijkstra
• stat-31-eda