Горизонтальное автомасштабирование Pod с использованием REST API, предоставляемого приложением в контейнере

Я использую minikube в Windows, есть только один узел "master".

Развернутое приложение весенней загрузки имеет конечную точку REST, которая указывает количество клиентов, обслуживаемых в настоящее время. Я хотел бы масштабировать по горизонтали или автоматически вращать модуль, когда количество запросов достигает некоторого предела.

Lets say:
There is 1 pod in the cluster.
If the request limit reached 50 (for Pod 1), spin up a new pod.
If the request limit reached 50 for Pod 1 and Pod 2, spin up a new Pod (Pod 3).

Я попытался выяснить, как этого добиться, я не смог ничего понять. Все, что я смог найти, - это масштабирование с использованием ЦП с помощью HorizontalPodAutoscaler (HPA). Было бы полезно получить руководство о том, как этого добиться с помощью Kubernetes HPA.


kubernetes minikube kubernetes-pod autoscaling
person Anthony    schedule 11.09.2019    source источник
comment
Обычно автоматическое масштабирование узлов происходит из базовой инфраструктуры, если используется AWS, затем группы автомасштабирования, если используется Azure, затем наборы масштабирования. Если вы хотите масштабировать POD, вам нужно начать смотреть на входные контроллеры kubernetes, они могут работать с входящими балансировщиками нагрузки, чтобы определить, нужно ли запускать новый Pod.   -  person Callum Linington    schedule 11.09.2019
comment
@CallumLinington, автоматическое масштабирование горизонтальных модулей предназначено именно для масштабирования модулей. вход и автомасштабирование узла не имеют к этому никакого отношения.   -  person Markus Dresch    schedule 11.09.2019
comment
Помимо HPA, он используется только для использования ЦП, а не для ограничения количества запросов, которое запрашивает OP. А поскольку балансировщики нагрузки отслеживают соединения, они идеально подходят для определения потребности в развертывании новых узлов.   -  person Callum Linington    schedule 11.09.2019
comment
Приложение уже отслеживает соединения, и есть REST api, когда нажатие дает количество подключений. При необходимости я могу использовать счетчики подключений, отслеживаемые Load Balancer. В любом случае для меня это нормально, мой вариант использования - масштабировать поды, когда соединение достигает порогового значения.   -  person Anthony    schedule 11.09.2019

Ответы (1)


arrow_upward
1
arrow_downward

Я считаю, что вы можете начать с автоматическое масштабирование в статье о пользовательских показателях. Насколько я понимаю, это достижимо с использованием пользовательских метрик в сочетании с адаптером Prometheus для API метрик Kubernetes (реализация API custom.metrics.k8s.io с использованием Prometheus).

Адаптер Prometheus для репозитория Kubernetes Metrics API содержит реализацию Kubernetes API метрики ресурсов и API пользовательских показателей.

Таким образом, этот адаптер подходит для использования с autoscaling / v2 Horizontal Pod Autoscaler в Kubernetes 1.6+.

Информация из автоматическое масштабирование по специальным показателям:

Обратите внимание, что вы можете указать другие метрики ресурсов, помимо ЦП. По умолчанию единственной другой поддерживаемой метрикой ресурсов является память. Эти ресурсы не меняют имена от кластера к кластеру и всегда должны быть доступны, пока доступен API metrics.k8s.io.

Первый из этих альтернативных типов метрик - метрики пакета. Эти метрики описывают поды, усредняются по подам и сравниваются с целевым значением для определения количества реплик. Они работают так же, как метрики ресурсов, за исключением того, что поддерживают только целевой тип AverageValue.

Метрики пода указываются с помощью такого блока метрик:

type: Pods
pods:
  metric:
    name: packets-per-second
  target:
    type: AverageValue
    averageValue: 1k

Второй альтернативный тип метрики - метрики объекта. Эти метрики описывают другой объект в том же пространстве имен вместо описания модулей. Показатели не обязательно берутся из объекта; они только описывают это. Метрики объекта поддерживают целевые типы как Value, так и AverageValue. С помощью Value цель сравнивается напрямую с метрикой, возвращаемой API. При использовании AverageValue значение, возвращаемое API настраиваемых показателей, делится на количество подов перед сравнением с целевым. Следующий пример - это YAML-представление метрики "запросов в секунду".

type: Object
object:
  metric:
    name: requests-per-second
  describedObject:
    apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    name: main-route
  target:
    type: Value
    value: 2k

Также, возможно, нижеследующее будет полезно для ваших будущих расследований:

Автоматическое масштабирование и др. конкретные показатели

Автоматическое масштабирование метрик, не связанных с объектами Kubernetes

Надеюсь, это поможет

person Vit    schedule 27.09.2019
comment
Спасибо за вклад. Автомасштабирование не проблема. Но главная проблема заключается в том, чтобы перейти к конкретному модулю, который принял запрос. См. Это: stackoverflow.com/q/58007073/11836838 - person Anthony; 30.09.2019
comment
@VKR Я новичок в Kubernetes и запутался с HPA. Нужен ли нам Prometheus и адаптер Prometheus с автомасштабированием / v2beta2? В настоящий момент я использую пружинный привод и Prometheus, и он отлично работает для автоматического масштабирования по количеству запросов. - person Chandresh Mishra; 23.11.2019