#Настройка HPA

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

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

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

После создания horizontal pod autoscaler платформа начинает опрашивать метрики использования ресурсов CPU и/или памяти на Pod. Когда эти метрики становятся доступны, horizontal pod autoscaler вычисляет соотношение текущего использования метрики к заданному целевому использованию и соответствующим образом масштабирует количество Pod вверх или вниз. Опрос и масштабирование выполняются через регулярные интервалы, однако появление метрик может занять одну-две минуты.

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

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

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

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

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

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

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

Horizontal Pod Autoscaler поддерживают следующие метрики:

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

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

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

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

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

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

Вы можете создать horizontal pod autoscaler с помощью command line interface, определив YAML-файл и используя команду kubectl create. В следующем примере показано autoscaling для объекта Deployment. Исходное развертывание требует 3 Pod. Объект HPA увеличивает минимум до 5. Если использование CPU на Pod достигает 75%, количество Pod увеличивается до 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
     metrics:
       - type: Resource
         resource:
           name: cpu
           target:
             type: Utilization
             averageUtilization: 75
   1. Используйте API autoscaling/v2.
   2. Имя ресурса HPA.
   3. Имя deployment, который нужно масштабировать.
   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 вы можете просмотреть новое состояние deployment, выполнив следующую команду:

   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

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

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

2. В левой панели навигации нажмите Workloads > Deployments.

3. Нажмите Имя Deployment.

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

5. Выберите Horizontal Scaling и завершите настройку политики.

   Параметр	Описание
   Pod Count	После успешного создания deployment необходимо определить Minimum Pod Count, соответствующее известным и регулярным изменениям объема бизнеса, а также Maximum Pod Count, которое может быть поддержано quota пространства имен при высокой бизнес-нагрузке. Максимальное или минимальное количество Pod можно изменить после настройки, и рекомендуется сначала получить более точное значение с помощью нагрузочного тестирования, а затем постоянно корректировать его в процессе использования, чтобы оно соответствовало бизнес-требованиям.
   Trigger Policy	Укажите список Metrics, чувствительных к изменениям бизнеса, и их Target Thresholds, которые запускают действия по масштабированию вверх или вниз. Например, если вы зададите CPU Utilization = 60%, то как только использование CPU отклонится от 60%, платформа начнет автоматически корректировать количество Pod на основе недостаточного или избыточного распределения ресурсов в текущем deployment. Примечание: Типы метрик включают встроенные метрики и custom metrics. Custom metrics применяются только к deployment в native applications, и сначала необходимо добавить custom metrics.
   Scale Up/Down Step (Alpha)	Для сценариев с определенными требованиями к скорости масштабирования вы можете постепенно адаптироваться к изменениям бизнес-объема, указав Scale-Up Step или Scale-Down Step. Для шага масштабирования вниз можно настроить Stability Window, значение по умолчанию — 300 секунд, то есть перед выполнением действий по масштабированию вниз необходимо подождать 300 секунд.

6. Нажмите Update.

#Использование Custom Metrics для HPA

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

#Требования

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

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

Традиционный 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
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

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

#HPA для Custom Metrics

Чтобы использовать custom metrics, необходимо установить prometheus-operator и custom-metrics-api. После установки custom-metrics-api предоставляет большое количество ресурсов custom metric:

{
  "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 с custom metrics отличается от традиционного HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: demo
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Pods
      pods:
        metric:
          name: metric-demo
        target:
          type: AverageValue
          averageValue: 10

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

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

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

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

{
      "describedObject": {  # Described object (Pod)
        "kind": "Pod",
        "namespace": "monitoring",
        "name": "nginx-788f78d959-fd6n9",
        "apiVersion": "/v1"
      },
      "metricName": "metric-demo",
      "timestamp": "2020-02-5T04:26:01Z",
      "value": "50"
}

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

#Совместимость HPA для Custom Metrics

YAML для HPA с custom metrics на самом деле совместим с исходными 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 — среднее значение, полученное для каждого Pod
• targetAverageUtilization — использование, вычисленное на основе прямого значения

Ссылка на алгоритм:

replicas = ceil(sum(CurrentPodsCPUUtilization) / Target)

#Изменения в autoscaling/v2

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

apiVersion: autoscaling/v2
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: 80
          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 auto-scaling будет запускаться только тогда, когда фактическое значение выходит за пределы диапазона ±10% от целевого порога.

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

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

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

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

  Примечание:

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

  • Если рассчитанное целевое количество Pod (в предыдущем примере 5) меньше количества Pod, скорректированного согласно Scale-Up Step (например, 10), платформа выполнит масштабирование только до 5 Pod.

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