HPA и VPA
Тема дорожной карты · Kubernetes
Horizontal Pod Autoscaler (HPA) и Vertical Pod Autoscaler (VPA) — взаимодополняющие механизмы автомасштабирования Kubernetes, регулирующие соответственно количество реплик Pod'а и запросы ресурсов CPU/памяти, выделяемые отдельным контейнерам. HPA — встроенный контроллер Kubernetes, масштабирующий Deployment, StatefulSet и ReplicaSet путём сравнения текущих метрик — загрузки CPU из Metrics Server, пользовательских метрик из Prometheus через Custom Metrics API или внешних метрик — с порогами, заданными в spec.metrics ресурса HorizontalPodAutoscaler. VPA (из группы API autoscaling.k8s.io/v1) анализирует историческое потребление ресурсов контейнерами Pod'ов и либо рекомендует, либо автоматически применяет обновлённые значения resources.requests и resources.limits, заменяя Pod'ы правильно подобранными при настройке updateMode: Auto. HPA и VPA не должны оба нацеливаться на cpu для одного Deployment одновременно; распространённый паттерн — использовать VPA в режиме updateMode: Off (только рекомендации) совместно с HPA с фиксированным минимальным количеством реплик, тогда как Cluster Autoscaler или Karpenter обрабатывает масштабирование на уровне узлов, когда ожидающие Pod'ы не могут быть запланированы.
Как это работает
HPA и VPA покрывает day-2 работу эксплуатации Kubernetes-кластера: обновления, node maintenance, capacity planning, backup и DR, оптимизация стоимости, multi-tenancy изоляция. Обновления следуют графику deprecation Kubernetes (один minor каждые 4 месяца); node maintenance использует cordon + drain; backups через Velero или CSI snapshots. DR требует регулярных тренировок — не только документации.
Когда применять
Установите HPA и VPA практики до того, как кластер станет критичным для выручки. Запланируйте первую 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 кластере ежемесячно.