Политики масштабирования Kubernetes HPA (с настраиваемыми метриками)

Начиная с Kubernetes v1.18, v2beta2 API позволяет настраивать поведение масштабирования с помощью поля поведения Horizontal Pod Autoscalar (HPA). Я планирую применить HPA с настраиваемыми показателями к StatefulSet.

Вариант использования, который я рассматриваю, - это масштабирование с использованием настраиваемой метрики (например, количества пользовательских сеансов в моем приложении), но HPA не будет уменьшаться вообще. Этот вариант использования также описывается усовершенствованиями K8s SIG-Autoscaling - Настраиваемая скорость масштабирования для HPA ›› История 4: Масштабируйте как обычно, не уменьшайте.

behavior:
  scaleDown:
    policies:
    - type: pods
      value: 0

Пользовательские сеансы могут оставаться активными от минут до часов. Начиная с 1 реплики StatefulSet, когда количество пользовательских сеансов достигает верхнего предела (показанного с помощью сборщика Prometheus, а затем настроенного с использованием параметра настраиваемой метрики HPA), модули приложений будут масштабироваться. Новые модули начнут обслуживать новых пользователей.

Поскольку это StatefulSet, который нельзя просто резко уменьшить, мне нужна помощь в способах уменьшения масштаба, когда количество сеансов пользователей на новых репликах снижается до 0. Ссылка выше говорит о том, что уменьшение масштаба можно контролировать с помощью отдельного процесса. Не знаете, как это сделать? Ищем указатели.

Спасибо.


person smulkutk    schedule 25.06.2020    source источник
comment
Из любопытства, есть ли причина, по которой вы используете StatefulSets?   -  person Rico    schedule 25.06.2020
comment
Приложение создано с учетом состояния (не без состояния). Он обрабатывает входящий запрос от пользователя, сохраняет свои пользовательские параметры и использует их для обработки последующих запросов.   -  person smulkutk    schedule 25.06.2020
comment
Где он хранит пользователя и параметры?   -  person Rico    schedule 25.06.2020
comment
Он хранит пользовательские данные локально в модуле, а также записывает их в базу данных.   -  person smulkutk    schedule 26.06.2020
comment
если окончательное постоянное состояние находится в базе данных (источник истины), а локальные данные - это скорее кеш, тогда я думаю, что это скорее служба без сохранения состояния, и обычно достаточно просто развертывания.   -  person Rico    schedule 26.06.2020
comment
Технически ты прав. Но когда модуль обслуживает / обрабатывает пользовательский запрос тысяч пользователей, уменьшение масштаба приведет к срыву запросов в полете и, таким образом, приведет к размещению приложения в центре города для некоторых пользователей. Пользователям придется заново устанавливать новые сеансы. Следовательно, я искал изящный способ уменьшения масштаба. Было бы неплохо внести улучшения в политику масштабирования HPA, чтобы иметь отдельные настраиваемые метрики, которые можно было бы использовать только для уменьшения масштаба.   -  person smulkutk    schedule 27.06.2020


Ответы (1)


Вы можете использовать значения periodSeconds и stabilizationWindowSeconds для управления временем, которое пройдет между завершением работы модулей, например:

  behavior:
    scaleDown:
      stabilizationWindowSeconds: 10
      policies:
      - type: Pods
        value: 1
        periodSeconds: 20

Таким образом, он будет уменьшаться на 1 модуль каждые ~ 30 секунд (или любое другое значение, которое будет использоваться в periodSeconds и stabilizationWindowSeconds). Время может меняться в зависимости от stabilizationWindowSeconds значений с течением времени.

periodSeconds описывает, сколько времени пройдет между завершением работы каждого модуля, максимальное значение - 1800 секунд (30 минут).

stabilizationWindowSeconds когда метрики указывают, что цель должна быть уменьшена, этот алгоритм анализирует ранее рассчитанные желаемые состояния и использует максимальное значение из указанного интервала. Для уменьшения по умолчанию значение 300, максимальное значение - 3600 (один час).

person Mariusz K.    schedule 25.06.2020