Режимы работы VPA

VPA может работать в двух режимах:

  • Автоматическое изменение запросов ресурсов:

    • InPlaceOrRecreate (по умолчанию в Kubernetes, начиная с версии 1.33) — VPA пытается изменить ресурсы без пересоздания подов. Если обновить ресурсы «на месте» (in-place) невозможно, VPA переходит к схеме, аналогичной режиму Recreate: под, для которого невозможно обновить ресурсы, вытесняется, и вместо него контроллер создает новый под с обновленными ресурсами.

      Чтобы использовать режим InPlaceOrRecreate в Kubernetes до версии 1.33, включите экспериментальную функцию (feature gate) InPlacePodVerticalScaling в настройках модуля control-plane-manager.

    • Auto (по умолчанию в Kubernetes до версии 1.33) — VPA изменяет ресурсы без пересоздания подов, но при необходимости действует аналогично режиму Recreate и перезапускает под. Это устаревший режим, и его поддержка будет прекращена в будущих версиях Deckhouse Kubernetes Platform (DKP).

    • Recreate — VPA может изменять ресурсы у работающих подов, перезапуская их. В случае одного пода (replicas: 1) это приведет к недоступности сервиса на время перезапуска. VPA не пересоздает поды, если они были созданы без контроллера.

  • Только рекомендации, без изменения ресурсов:

    • Initial — ресурсы подов изменяются только при их создании, но не в процессе работы.

    • Off — VPA не меняет ресурсы автоматически. Однако, с его помощью можно просматривать рекомендуемые ресурсы с помощью команды d8 k describe vpa.

При использовании VPA и включении соответствующего режима, запрашиваемые ресурсы устанавливаются автоматически на основе данных из Prometheus. Также возможно настроить систему таким образом, чтобы она только рекомендовала ресурсы, но не изменяла их. Подробнее про включение и настройку VPA можно почитать в разделе «Администрирование».

Ограничения VPA

Перед использованием вертикального масштабирования (VPA) необходимо учитывать ряд ограничений:

  • Перезапуск подов при изменении ресурсов:
    • Обновление запрашиваемых ресурсов — экспериментальная функция, каждый раз при изменении ресурсов VPA пересоздаёт под, и он может быть назначен на другой узел;
    • Поды могут пересоздаваться на других узлах.
  • Совместимость с HPA:
    • VPA не рекомендуется использовать совместно с HPA по CPU и памяти;
    • VPA можно использовать с HPA с custom/external метриками.

  • Проблемы с большими кластерами — VPA может работать и в больших кластерах, но нагрузка на VPA возрастает при росте числа подов.

  • Проблемы с Pending-подами — VPA может рекомендовать ресурсы выше доступных в кластере, из-за чего поды могут застрять в статусе Pending.

  • Проблемы при удалении VPA — если удалить VPA или отключить его (режим Off), ресурсы останутся в последнем измененном значении. Это может привести к путанице, когда в Helm указаны одни ресурсы, в контроллере — другие, а у подов — третьи.

  • Использование нескольких VPA-ресурсов на один под — может привести к непредсказуемому поведению.

При использовании VPA рекомендуется настроить Pod Disruption Budget.

VPA состоит из 3 компонентов:

  • Recommender — мониторит настоящее (делая запросы в Metrics API, который реализован в модуле prometheus-metrics-adapter) и прошлое потребление ресурсов (делая запросы в Trickster перед Prometheus) и предоставляет рекомендации по CPU и памяти для контейнеров.
  • Updater — проверяет, что у подов с VPA выставлены корректные ресурсы, если нет — убивает эти поды, чтобы контроллер пересоздал поды с новыми запрашиваемыми ресурсами.
  • Admission Plugin — задает запрашиваемые ресурсы при создании новых подов (контроллером или из-за активности Updater’а).

При изменении ресурсов компонентом Updater это происходит с помощью Eviction API, поэтому учитываются Pod Disruption Budget для обновляемых подов. Архитектура VPA