Как правильно настроить авто-масштабирование веб-приложения в Kubernetes что бы избежать overprovisioning?

Question

[splatt]

Допустим есть традиционное веб-приложение, построенное на микросервисах. Без какой-либо серьезной нагрузки, приложение потребляет минимальное количество ресурсов. Под нагрузкой, использование CPU растет линейно с количеством пользователей/запросов в секунду.

Если выставить значение resources.requests.cpu в низкое значение, например 5%, то без нагрузки все работает хорошо: мы можем запустить несколько микросервисов на одной ноде, итд. Но при увеличении нагрузки, HorizontalPodAutoscaler поптается увеличить количество инстансов (подов на микросервис) и из-за низкого значения requests они запускаются на одной и той же ноде, даже если общая нагрузка ноды более 90%. Это приводит к тому что нагрузка CPU ноды начинает превышать 95% и нода и приложения становятся нестабильными.

Если выставить значение resources.requests.cpu в более высокое, например 21%, то данной проблемы нет. При превышении нагрузки 84%+ HPA попытается добавить поды, а в ответ Cluster Auto Scaler добавляет новые ноды. Но мы по сути мы таким образом ограничиваем ноду максимум 4мя подами. При увеличении количества микросервисов эта проблема становится актуальнее и получается что мы делаем дикий overprovisioning и переплачиваем за ресурсы во много раз.

Что я упускаю? В более традиционных решениях, таких как ECS, такой проблемы не существует так как автомасштабирование подов и нод раздельно, и можно задать порог например 70% для ноды после которого в Auto Scaling Group создаются больше инстансов.

Можно задать Negative Pod Affinity и запретить запускать больше 1го пода одинакового типа на 1й ноде, но это выглядит как хак и приводит к тому, что для blue-green деплойментов требуется в два раза больше нод, даже если нагрузка минимальна.

Как правильно подходить к авто-масштабированию веб-приложений с помощью HorizontalPodAutoscaler и ClusterAutoScaler?

Comments

[Saboteur]

https://kubernetes.io/docs/concepts/scheduling-evi...

[splatt]

Saboteur, не очень понял, каким образом это помогает решить описанную проблему...

[Saboteur]

splatt, там же есть про то, как настраивать, чтобы поды распределялись по имеющися нодам. пробовать, экспериментировать.

[ZIK1337]

есть еще VPA, не пробовали?

[Zerg89]

type: Resource
resource:
  name: cpu
  target:
    type: Utilization
    averageUtilization: 60

With this metric the HPA controller will keep the average utilization of the pods in the scaling target at 60%. Utilization is the ratio between the current usage of resource to the requested resources of the pod. See Algorithm for more details about how the utilization is calculated and averaged.

[Zerg89]

splatt,
Хотя в вашем случае такое ограничение нужно

type: ContainerResource
containerResource:
  name: cpu
  container: application
  target:
    type: Utilization
    averageUtilization: 60