Вертикальное масштабирование

Модуль vertical-pod-autoscaler обеспечивает работу Vertical Pod Autoscaler (VPA) в Deckhouse Kubernetes Platform (DKP).

Подробнее о настройках модуля и примерах его использования можно узнать в соответствующем разделе документации.

Режимы работы 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 пересоздаёт под, и он может быть назначен на другой узел;
  • Поды могут пересоздаваться на других узлах.
• Совместимость с Horizontal Pod Autoscaler (HPA):
  • VPA не рекомендуется использовать совместно с HPA, выполняющим масштабирование по CPU или памяти;
  • VPA можно использовать совместно с HPA, выполняющим масштабирование по custom- или external-метрикам.

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

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

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

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

Архитектура модуля

Архитектура модуля vertical-pod-autoscaler на уровне 2 модели C4 и его взаимодействие с другими компонентами DKP показаны на следующей диаграмме:

Компоненты модуля

Модуль vertical-pod-autoscaler состоит из следующих компонентов:

1. Vpa-admission-controller (Deployment) — контроллер VPA, обслуживающий работу с кастомным ресурсом VerticalPodAutoscaler.

   Компонент vpa-admission-controller выполняет следующие действия:

   • валидирует кастомные ресурсы VerticalPodAutoscaler;
   • при создании пода (если для VPA не установлен режим Off) контроллер автоматически задаёт или меняет значения requests и limits в контейнерах, оптимизируя их по текущим рекомендациям. Значения limits контроллер изменяет только в том случае, если в параметре spec.resourcePolicy.containerPolicies.controlledValues политики управления ресурсами установлено значение RequestsAndLimits.

   Состоит из следующих контейнеров:

   • admission-controller — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для защищенного доступа к метрикам admission-controller. Является Open Source-проектом.

2. Vpa-updater (Deployment) — компонент VPA, проверяющий, что у подов с VPA выставлены корректные ресурсы. Vpa-updater выполняет in-place-обновление ресурсов через субресурс Kubernetes pods/resize, а если это невозможно или не подходит по политике управления ресурсами, вытесняет под.

   Состоит из следующих контейнеров:

   • updater — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для защищенного доступа к метрикам updater. Является Open Source-проектом.

3. Vpa-recommender (Deployment) — компонент VPA, определяющий рекомендации для requests на основе информации о прошлом и текущем потреблении ресурсов подами.

   Vpa-admission-controller и vpa-updater пересчитывают значения limits пропорционально requests в том случае, если в параметре spec.resourcePolicy.containerPolicies.controlledValues политики управления ресурсами установлено значение RequestsAndLimits.

   Состоит из следующих контейнеров:

   • recommender — основной контейнер;
   • kube-rbac-proxy — сайдкар-контейнер с авторизующим прокси на основе Kubernetes RBAC для защищенного доступа к метрикам recommender. Является Open Source-проектом.

Взаимодействия модуля

Модуль взаимодействует со следующими компонентами:

1. Kube-apiserver:

   • наблюдение за стандартными ресурсами ConfigMap, Node, LimitRange, Pod, а также за кастомными ресурсами VerticalPodAutoscaler и VerticalPodAutoscalerCheckpoint;
   • получение текущего потребления ресурсов через Metrics API;
   • вытеснение работающих подов при несоответствии спецификации ресурсов и рекомендуемых значений;
   • авторизация запросов на получение метрик.

2. Prometheus — получение истории метрик потребления ресурсов подом.

С модулем взаимодействуют следующие внешние компоненты:

1. Kube-apiserver:
   • валидация кастомных ресурсов VerticalPodAutoscaler;
   • изменение requests и limits в спецификации подов.
2. Prometheus — собирает метрики модуля.

Дополнительные ресурсы

• Включение вертикального масштабирования
• Параметры модуля control-plane-manager
• Документация модуля vertical-pod-autoscaler