VPA для Application

Что нужно знать перед уроком

M10 урок 4 — горизонтальное масштабирование (число реплик). Этот урок разбирает VerticalPodAutoscaler — масштабирование в другом измерении: корректировка запросов/лимитов ресурсов у существующих реплик.

Теория

VPA решает другую задачу, чем HPA

HPA (M10 урок 4) отвечает на вопрос «сколько реплик нужно?». VPA отвечает на принципиально другой вопрос: «сколько CPU/памяти нужно каждой реплике?». Это разные измерения масштабирования, которые могут (с оговорками — см. ниже) применяться совместно, но чаще выбирается что-то одно в зависимости от природы нагрузки приложения: горизонтально масштабируемые stateless-компоненты — через HPA, а компоненты, для которых важна корректировка индивидуальных ресурсных запросов (например, приложение с непредсказуемым, но одиночным паттерном потребления памяти) — через VPA.

updatePolicy.updateMode — как именно VPA применяет рекомендации

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: {{.Application.Instance.Name}}-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: {{.Application.Instance.Name}}
  updatePolicy:
    updateMode: "InPlaceOrRecreate"
  resourcePolicy:
    containerPolicies:
    - containerName: app
      minAllowed:
        memory: 100Mi
        cpu: 120m
      maxAllowed:
        memory: 300Mi
        cpu: 350m
      mode: Auto

Значения updateMode:

• InPlaceOrRecreate — актуальная рекомендуемая настройка (см. ниже про устаревание Auto): VPA пытается обновить ресурсы на месте, без пересоздания пода (используя механизм InPlacePodVerticalScaling), и только если это невозможно — прибегает к пересозданию пода с новыми значениями. Версии этого механизма важны: InPlacePodVerticalScaling — дефолтный режим начиная с Kubernetes 1.33+; для более старых кластеров (≤1.32) фичу нужно включать через feature gate InPlacePodVerticalScaling в конфигурации control-plane-manager (Deckhouse делает это автоматически для таких кластеров). А с выходом Kubernetes 1.35 («Timbernetes», KEP-1287) сам механизм in-place изменения ресурсов Pod’а графован в GA (stable) — то есть с 1.35 это уже безусловно доступная, не экспериментальная возможность платформы, а не «фича, зависящая от версии».
• Initial — VPA устанавливает рекомендованные значения только при создании пода, никогда не изменяя их у уже запущенного пода.
• Off — VPA только вычисляет рекомендации (видимые через d8 k describe vpa), но не применяет их автоматически — полезно для наблюдения за рекомендациями перед включением автоматического применения.

Важное уточнение об устаревании: значение updateMode: Auto объявлено устаревшим (deprecated) начиная с версии модуля vertical-pod-autoscaler 1.5.0 и должно быть заменено на InPlaceOrRecreate — в актуальных пакетах следует использовать именно InPlaceOrRecreate, а не Auto.

resourcePolicy.containerPolicies — границы на уровне контейнера

minAllowed/maxAllowed внутри containerPolicies для конкретного containerName — жёсткие границы, за пределы которых VPA не выйдет при рекомендациях, независимо от реальной наблюдаемой нагрузки. Это защита от экстремальных рекомендаций (например, VPA не должен предложить cpu: 16 для лёгкого вспомогательного контейнера, даже если краткосрочный всплеск нагрузки формально это оправдывал бы).

Разница между пересозданием и обновлением «на месте»

Пересоздание пода (traditional VPA behavior до InPlacePodVerticalScaling) означает краткосрочный простой конкретной реплики во время пересоздания — для stateless-приложений с несколькими репликами это обычно не критично (другие реплики продолжают обслуживать трафик), но для одиночных экземпляров или stateful-компонентов может создавать заметные перерывы в обслуживании. InPlaceOrRecreate минимизирует эту проблему, обновляя ресурсы без полного пересоздания пода везде, где это технически возможно.

Когда VPA полезнее HPA

Для типичного веб-приложения с равномерно распределяемой нагрузкой между репликами HPA — естественный выбор. VPA более уместен, когда: (а) приложение принципиально не может масштабироваться горизонтально (например, компонент с внутренним состоянием, не поддерживающий несколько одновременно активных экземпляров), (б) начальные requests/limits, заданные разработчиком в values.yaml, заведомо неточны и должны корректироваться по факту наблюдаемого потребления, (в) нагрузка приложения колеблется по объёму потребления ресурсов одной репликой, а не по количеству одновременных запросов, требующих больше параллельных обработчиков.

Частые ошибки и подводные камни

• Использовать устаревшее значение updateMode: Auto вместо InPlaceOrRecreate в новых пакетах. Хотя Auto может по-прежнему работать в некоторых версиях, официально рекомендуемое значение — InPlaceOrRecreate.
• Комбинировать HPA и VPA на одном и том же ресурсе (CPU/память) без понимания рисков конфликта. Одновременное управление одной и той же метрикой ресурса и через горизонтальное, и через вертикальное масштабирование может привести к нестабильному, «дёргающемуся» поведению — если оба механизма нужны, стоит разносить их по разным метрикам (например, HPA по кастомной метрике очереди, VPA по CPU/памяти).
• Не задавать minAllowed/maxAllowed. Без явных границ VPA может выдать рекомендации, выходящие далеко за разумные пределы при аномальных, кратковременных всплесках нагрузки.

Практика в кластере

1
2

d8 k get vpa -n course-m10-umami
d8 k describe vpa umami-vpa -n course-m10-umami | grep -A10 "Recommendation:"

Разверните VPA пакета Umami в режиме Off, понаблюдайте за рекомендациями некоторое время, а затем переключите на InPlaceOrRecreate и убедитесь, что ресурсы корректируются в рамках заданных minAllowed/maxAllowed.

Практика разработки

Добавьте в пакет Umami VerticalPodAutoscaler с updateMode: InPlaceOrRecreate и разумными minAllowed/maxAllowed для основного контейнера приложения, основанными на изначально заданных resources.requests/limits в values.yaml.

Шпаргалка команд урока

1
2

d8 k get vpa -A
d8 k describe vpa <name> -n <namespace>

Вопросы для самопроверки

Рекомендуемая литература

Официальная документация

• Deckhouse — VPA (пользователь)
• Deckhouse — VPA (архитектура)
• Deckhouse — Release notes Deckhouse
• kubernetes.io — Kubernetes v1.35: Timbernetes (In-place Update of Pod Resources — GA, KEP-1287).

Статьи и блоги

• Deckhouse Prom++: оптимизация Prometheus — Flant на Habr.
• Deckhouse Prom++: как мы посадили Prometheus на RAM-диету — Flant на Habr.
• Kubernetes на базе Deckhouse: встроенный мониторинг и логирование — обзор возможностей DKP на Habr.

Книги

• Brendan Burns, David Oppenheimer. Designing Distributed Systems. 2018. ISBN 978-1491983645.
• Marko Lukša. Kubernetes in Action. 2nd ed., 2022. ISBN 978-1617297618.

Связанные материалы

• Предыдущий урок: M10.04 — HPA для Application.
• Следующий урок: M10.06 — PDB для Application.

✓ Урок пройден — все вопросы самопроверки отвечены верно