#Настройка HPA

HPA (Horizontal Pod Autoscaler) автоматически масштабирует количество подов вверх или вниз на основе заданных политик и метрик, позволяя приложениям справляться с внезапными всплесками нагрузки при оптимальном использовании ресурсов в периоды низкой активности.

#Понимание Horizontal Pod Autoscalers

Вы можете создать горизонтальный автоскейлер подов, чтобы указать минимальное и максимальное количество подов, которые вы хотите запустить, а также целевое использование CPU или памяти для ваших подов.

После создания горизонтального автоскейлера платформа начинает опрашивать метрики ресурсов CPU и/или памяти на подах. Когда эти метрики становятся доступны, автоскейлер вычисляет отношение текущего использования метрики к желаемому значению и масштабирует количество подов вверх или вниз соответственно. Запрос метрик и масштабирование происходят с регулярным интервалом, но может пройти от одной до двух минут, прежде чем метрики станут доступны.

Для replication controllers такое масштабирование напрямую соответствует количеству реплик replication controller. Для deployment configurations масштабирование напрямую соответствует количеству реплик deployment configuration. Обратите внимание, что автоскейлинг применяется только к последнему деплою в фазе Complete.

Платформа автоматически учитывает ресурсы и предотвращает ненужное автоскейлинг во время всплесков ресурсов, например, при запуске. Поды в состоянии unready имеют 0 использования CPU при масштабировании вверх, а автоскейлер игнорирует такие поды при масштабировании вниз. Поды без известных метрик считаются с 0% использования CPU при масштабировании вверх и 100% CPU при масштабировании вниз. Это обеспечивает большую стабильность при принятии решений HPA. Для использования этой функции необходимо настроить readiness checks, чтобы определить, готов ли новый под к использованию.

#Как работает HPA?

Горизонтальный автоскейлер подов (HPA) расширяет концепцию автоскейлинга подов. HPA позволяет создавать и управлять группой балансируемых по нагрузке узлов. HPA автоматически увеличивает или уменьшает количество подов при превышении заданного порога CPU или памяти.

HPA работает как управляющий цикл с периодом синхронизации по умолчанию 15 секунд. В этот период controller manager опрашивает использование CPU, памяти или обоих параметров в соответствии с конфигурацией HPA. Controller manager получает метрики использования из resource metrics API для каждого пода, на который направлен HPA.

Если задана целевая величина использования, контроллер вычисляет значение использования в процентах от соответствующего запроса ресурса на контейнерах каждого пода. Затем контроллер берет среднее значение использования по всем целевым подам и формирует коэффициент, который используется для масштабирования желаемого количества реплик.

#Поддерживаемые метрики

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

Важно: Для автоскейлинга на основе памяти использование памяти должно пропорционально увеличиваться и уменьшаться вместе с количеством реплик. В среднем:

• Увеличение количества реплик должно приводить к общему снижению использования памяти (working set) на под.
• Уменьшение количества реплик должно приводить к общему увеличению использования памяти на под.
• Используйте платформу для проверки поведения памяти вашего приложения и убедитесь, что оно соответствует этим требованиям перед использованием автоскейлинга на основе памяти.

#Предварительные требования

Убедитесь, что компоненты мониторинга развернуты в текущем кластере и работают корректно. Вы можете проверить статус развертывания и состояние компонентов мониторинга, нажав в правом верхнем углу платформы > Platform Health Status..

#Создание горизонтального автоскейлера подов

#Использование CLI

Вы можете создать горизонтальный автоскейлер подов с помощью командной строки, определив YAML-файл и используя команду kubectl create. В следующем примере показан автоскейлинг для объекта Deployment. Изначально развертывание требует 3 пода. Объект HPA увеличивает минимум до 5. Если использование CPU на подах достигает 75%, количество подов увеличивается до 7:

1. Создайте YAML-файл с именем hpa.yaml со следующим содержимым:

   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: hpa-demo
     namespace: default
   spec:
     maxReplicas: 7
     minReplicas: 3
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: deployment-demo
     targetCPUUtilizationPercentage: 75
   1. Используйте API autoscaling/v2.
   2. Имя ресурса HPA.
   3. Имя деплоя для масштабирования.
   4. Максимальное количество реплик для масштабирования вверх.
   5. Минимальное количество реплик для поддержания.
   6. Укажите версию API объекта для масштабирования.
   7. Укажите тип объекта. Объект должен быть Deployment, ReplicaSet или StatefulSet.
   8. Целевой ресурс, к которому применяется HPA.
   9. Целевой процент использования CPU, при котором происходит масштабирование.

2. Примените YAML-файл для создания HPA:

   kubectl create -f hpa.yaml

   Пример вывода:

   horizontalpodautoscaler.autoscaling/hpa-demo created

3. После создания HPA вы можете просмотреть текущее состояние деплоя, выполнив команду:

   kubectl get deployment deployment-demo

   Пример вывода:

   NAME              READY   UP-TO-DATE   AVAILABLE   AGE
   deployment-demo   5/5     5            5           3m

4. Также можно проверить статус вашего HPA:

   kubectl get hpa hpa-demo

   Пример вывода:

   NAME         REFERENCE                  TARGETS    MINPODS   MAXPODS   REPLICAS   AGE
   hpa-demo   Deployment/deployment-demo   0%/75%     3         7         3          2m

#Использование веб-консоли

1. Войдите в Container Platform.

2. В левой навигационной панели выберите Workloads > Deployments.

3. Кликните на Имя Deployment.

4. Прокрутите вниз до раздела Elastic Scaling и нажмите Update справа.

5. Выберите Horizontal Scaling и заполните конфигурацию политики.

   Параметр	Описание
   Pod Count	После успешного создания деплоя необходимо оценить Минимальное количество подов, соответствующее известным и регулярным изменениям бизнес-объема, а также Максимальное количество подов, которое может поддерживаться квотой namespace при высокой нагрузке. Максимальное или минимальное количество подов можно изменять после настройки, рекомендуется сначала получить более точное значение через нагрузочное тестирование и затем корректировать в процессе эксплуатации для удовлетворения бизнес-потребностей.
   Trigger Policy	Перечислите Метрики, чувствительные к изменениям бизнеса, и их Целевые пороги, при достижении которых происходит масштабирование вверх или вниз. Например, если вы установите CPU Utilization = 60%, то при отклонении использования CPU от 60% платформа начнет автоматически корректировать количество подов в зависимости от недостатка или избытка ресурсов текущего деплоя. Примечание: Типы метрик включают встроенные и пользовательские. Пользовательские метрики применимы только к деплоям в нативных приложениях, и их необходимо предварительно добавить custom metrics .
   Scale Up/Down Step (Alpha)	Для бизнесов с особыми требованиями к скорости масштабирования можно постепенно адаптироваться к изменениям объема, задавая Шаг масштабирования вверх или Шаг масштабирования вниз. Для шага масштабирования вниз можно настроить Окно стабильности, по умолчанию 300 секунд, что означает необходимость ожидания 300 секунд перед выполнением действия масштабирования вниз.

6. Нажмите Update.

#Использование пользовательских метрик для HPA

HPA с пользовательскими метриками расширяет оригинальный HorizontalPodAutoscaler, поддерживая дополнительные метрики помимо CPU и памяти.

#Требования

• kube-controller-manager: horizontal-pod-autoscaler-use-rest-clients=true
• Предустановленный metrics-server
• Prometheus
• custom-metrics-api

#Традиционный (Core Metrics) HPA

Традиционный HPA поддерживает метрики использования CPU и памяти для динамического изменения количества экземпляров Pod, как показано в примере ниже:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-app-nginx
  namespace: test-namespace
spec:
  maxReplicas: 1
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-app-nginx
  targetCPUUtilizationPercentage: 50

В этом YAML scaleTargetRef указывает объект нагрузки для масштабирования, а targetCPUUtilizationPercentage задает метрику триггера по CPU.

#HPA с пользовательскими метриками

Для использования пользовательских метрик необходимо установить prometheus-operator и custom-metrics-api. После установки custom-metrics-api предоставляет множество ресурсов пользовательских метрик:

{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "custom.metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "namespaces/go_memstats_heap_sys_bytes",
      "singularName": "",
      "namespaced": false,
      "kind": "MetricValueList",
      "verbs": ["get"]
    },
    {
      "name": "jobs.batch/go_memstats_last_gc_time_seconds",
      "singularName": "",
      "namespaced": true,
      "kind": "MetricValueList",
      "verbs": ["get"]
    },
    {
      "name": "pods/go_memstats_frees",
      "singularName": "",
      "namespaced": true,
      "kind": "MetricValueList",
      "verbs": ["get"]
    }
  ]
}

Эти ресурсы являются подресурсами MetricValueList. Вы можете создавать правила через Prometheus для создания или поддержки подресурсов. Формат YAML HPA для пользовательских метрик отличается от традиционного HPA:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: demo
spec:
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: demo
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Pods
      pods:
        metricName: metric-demo
        targetAverageValue: 10

В этом примере scaleTargetRef указывает нагрузку.

#Определение условий триггера

• metrics — массив, поддерживающий несколько метрик
• тип метрики может быть: Object (описание ресурсов k8s), Pods (метрики для каждого Pod), Resources (встроенные метрики k8s: CPU, память), или External (обычно метрики вне кластера)
• Если пользовательская метрика не предоставляется Prometheus, необходимо создать новую метрику через ряд операций, например, создание правил в Prometheus

Основная структура метрики выглядит так:

{
      "describedObject": {  # Описываемый объект (Pod)
        "kind": "Pod",
        "namespace": "monitoring",
        "name": "nginx-788f78d959-fd6n9",
        "apiVersion": "/v1"
      },
      "metricName": "metric-demo",
      "timestamp": "2020-02-5T04:26:01Z",
      "value": "50"
}

Эти данные метрики собираются и обновляются Prometheus.

#Совместимость HPA с пользовательскими метриками

YAML HPA с пользовательскими метриками совместим с оригинальными core metrics (CPU). Пример записи:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
spec:
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: nginx
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 80
    - type: Resource
      resource:
        name: memory
        targetAverageValue: 200Mi

• targetAverageValue — среднее значение, полученное для каждого пода
• targetAverageUtilization — использование, рассчитанное из прямого значения

Алгоритм расчёта:

replicas = ceil(sum(CurrentPodsCPUUtilization) / Target)

#Обновления в autoscaling/v2beta2

autoscaling/v2beta2 поддерживает использование памяти:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx
  namespace: default
spec:
  minReplicas: 1
  maxReplicas: 3
  metrics:
    - resource:
        name: cpu
        target:
          averageUtilization: 70
          type: Utilization
      type: Resource
    - resource:
        name: memory
        target:
          averageUtilization:
          type: Utilization
      type: Resource
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx

Изменения: targetAverageUtilization и targetAverageValue заменены на target и преобразованы в комбинацию xxxValue и type:

• xxxValue: AverageValue (среднее значение), AverageUtilization (среднее использование), Value (прямое значение)
• type: Utilization (использование), AverageValue (среднее значение)

Примечания:

• Для метрик CPU Utilization и Memory Utilization автоскейлинг срабатывает только при отклонении фактического значения за пределы ±10% от целевого порога.

• Масштабирование вниз может повлиять на текущие бизнес-процессы; действуйте с осторожностью.

#Правила расчёта

При изменении бизнес-метрик платформа автоматически рассчитывает целевое количество подов, соответствующее объему бизнеса, согласно следующим правилам и корректирует масштабирование. Если бизнес-метрики продолжают колебаться, значение будет ограничено установленным Минимальным количеством подов или Максимальным количеством подов.

• Целевое количество подов для одной политики: ceil[(сумма фактических значений метрик) / (порог метрики)] . Это означает, что сумма фактических значений метрик всех подов делится на порог метрики, и результат округляется вверх до ближайшего целого числа. Например: если сейчас 3 пода с использованием CPU 80%, 80% и 90%, а установлен порог CPU 60%, то по формуле количество подов будет автоматически скорректировано до: ceil[(80%+80%+90%) / 60%] = ceil 4.1 = 5 подов.

  Примечание:

  • Если рассчитанное целевое количество подов превышает установленное Максимальное количество подов (например, 4), платформа масштабирует только до 4 подов. Если после изменения максимума метрики остаются высокими, возможно, потребуется использовать альтернативные методы масштабирования, например, увеличить квоту подов в namespace или добавить аппаратные ресурсы.

  • Если рассчитанное целевое количество подов (в примере 5) меньше количества подов, рассчитанного с учётом Шага масштабирования вверх (например, 10), платформа масштабирует только до 5 подов.

• Целевое количество подов для нескольких политик: берется максимальное значение из результатов расчётов каждой политики.