#Настройка 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% при масштабировании вниз. Это обеспечивает большую стабильность при принятии решений HPA. Для использования этой функции необходимо настроить readiness проверки, чтобы определить, готов ли новый под к использованию.

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

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

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

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

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

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

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

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

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

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

#Создание Horizontal Pod Autoscaler

#Использование 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 и заполните конфигурацию политики.

   Параметр	Описание
   Количество подов	После успешного создания деплоя необходимо оценить Минимальное количество подов, соответствующее известным и регулярным изменениям бизнес-объема, а также Максимальное количество подов, которое может поддерживаться квотой namespace при высокой нагрузке. Максимальное или минимальное количество подов можно изменять после настройки, рекомендуется сначала получить более точное значение через нагрузочное тестирование и постоянно корректировать в процессе эксплуатации для удовлетворения бизнес-потребностей.
   Политика триггера	Укажите Метрики, чувствительные к изменениям бизнеса, и их Целевые пороги для запуска действий масштабирования вверх или вниз. Например, если вы установите CPU Utilization = 60%, как только использование CPU отклонится от 60%, платформа начнет автоматически корректировать количество подов на основе недостаточного или избыточного распределения ресурсов текущего деплоя. Примечание: Типы метрик включают встроенные и пользовательские. Пользовательские метрики применимы только к деплоям в нативных приложениях, и их необходимо предварительно добавить custom metrics .
   Шаг масштабирования (альфа)	Для бизнесов с особыми требованиями к скорости масштабирования можно постепенно адаптироваться к изменениям объема, задавая Шаг масштабирования вверх или Шаг масштабирования вниз. Для шага масштабирования вниз можно настроить Окно стабильности, по умолчанию 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 подов.

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