Использование Горизонтального Стручкового Автомасштабирования наряду с запросами ресурсов и ограничениями

Question

Скажем, у нас есть следующее развертывание:

apiVersion: apps/v1
kind: Deployment
metadata:
  ...
spec:
  replicas: 2
  template:
    spec:
      containers:
        - image: ...
          ...
          resources:
            requests:
              cpu: 100m
              memory: 50Mi
            limits:
              cpu: 500m
              memory: 300Mi

И мы также создаем объект HorizontalPodAutoscaler, который автоматически увеличивает / уменьшает количество модулей в зависимости от средней загрузки ЦП.Я знаю, что HPA вычислит количество модулей на основе ресурса запросов , но что, если я хочу, чтобы контейнеры могли запрашивать больше ресурсов перед горизонтальным масштабированием?

У меня есть двавопросы:

1) Ресурсы ограничивают , даже используемые K8s, когда определен HPA?

2) Могу ли я сказать HPA, чтобы он масштабировался на основе ресурса ограничивает , а не запросы?Или как средство реализации такого элемента управления, могу ли я установить значение targetUtilization более 100%?

Answer 1

Нет, HPA вообще не смотрит на границы.Вы можете указать целевое использование для любого значения даже выше, чем 100%.

Answer 2

Привет в развертывании у нас есть ресурсы запросов и ограничений . Согласно документации здесь эти параметры действуют до того, как HPA получит основную роль в качестве автоматического масштабирования:

1. При создании Pod планировщик Kubernetes выбирает узел для Стручок для бега. Каждый узел имеет максимальную емкость для каждого из типы ресурсов: объем процессора и памяти , которые он может обеспечить Бобы.
2. Затем kubelet запускает контейнер контейнера, передает ограничения ЦП и памяти в среду выполнения контейнера.
3. Если контейнер превышает предел памяти, он может быть завершен . Если он перезапускается, kubelet перезапустит его, как и при любом другом типе сбоя во время выполнения.

Если Контейнер превышает свой запрос памяти, вполне вероятно, что его Pod будет удален всякий раз, когда узлу не хватит памяти.

С другой стороны:

Горизонтальный стручковый автоскалер реализован в виде контура управления с периодом, контролируемым диспетчером контроллера (со значением по умолчанию 15 секунд). Диспетчер контроллеров запрашивает использование ресурсов по метрикам, указанным в каждом определении HorizontalPodAutoscaler.

Примечание: Обратите внимание, что если в некоторых контейнерах модуля нет соответствующего набора запросов ресурсов, загрузка ЦП для модуля не будет определена, и автоскалер не будет предпринимать никаких действий для этого показателя.

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