#Настройка 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’ов это масштабирование напрямую соответствует replicas replication controller’а. Для deployment configuration’ов масштабирование напрямую соответствует количеству replicas deployment configuration’а. Обратите внимание, что autoscaling применяется только к последнему deployment в фазе Complete.

Платформа автоматически учитывает ресурсы и предотвращает ненужное autoscaling во время всплесков потребления ресурсов, например при запуске. Для pod’ов в состоянии unready при масштабировании вверх используется 0 CPU, а autoscaler игнорирует такие pod’ы при масштабировании вниз. Для pod’ов без известных метрик при масштабировании вверх используется 0% CPU, а при масштабировании вниз — 100% CPU. Это повышает стабильность при принятии решения HPA. Чтобы использовать эту функцию, необходимо настроить checks на готовность, чтобы определить, готов ли новый 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 вычисляет значение использования как процент от эквивалентного request ресурса для контейнеров в каждом pod. Затем controller вычисляет среднее значение использования по всем целевым pod’ам и формирует отношение, которое используется для масштабирования требуемого числа replicas.

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

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

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

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

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

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

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

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

Вы можете создать horizontal pod autoscaler с помощью command line interface, определив YAML-файл и используя команду kubectl create. В следующем примере показано autoscaling для объекта Deployment. Исходное deployment требует 3 pod’а. Объект HPA увеличивает minimum до 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. Максимальное количество replicas, до которого выполняется масштабирование.
   5. Минимальное количество replicas, которое необходимо поддерживать.
   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 Name.

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

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

   Параметр	Описание
   Pod Count	После успешного создания deployment необходимо определить Minimum Pod Count, соответствующее известным и регулярным изменениям объема бизнес-нагрузки, а также Maximum Pod Count, которое может поддерживаться quota namespace при высокой бизнес-нагрузке. Максимальное или минимальное количество 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.

#Custom Metrics HPA

Чтобы использовать 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, memory) или External (обычно метрики вне cluster)
• Если 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.

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

YAML для Custom Metrics 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 — среднее значение, полученное для каждого 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 autoscaling будет запускаться только тогда, когда фактическое значение выходит за пределы диапазона ±10% от целевого порога.

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

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

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

• Target Pod Count для одной политики: 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’ов. Если после изменения maximum pod count метрики продолжают оставаться постоянно высокими, может потребоваться использовать альтернативные методы масштабирования, например увеличить quota pod’ов namespace или добавить аппаратные ресурсы.

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

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