Центр знаний DevOps
Центр знаний DevOps

Практическое руководство по настройке Horizontal Pod Autoscaler (HPA) в Kubernetes

Обеспечьте оптимальную производительность приложений и экономическую эффективность с помощью этого практического руководства по настройке Horizontal Pod Autoscaler (HPA) в Kubernetes. Узнайте, как настраивать HPA с использованием метрик ЦП, пользовательских и внешних метрик, а также освойте расширенные сценарии масштабирования с помощью `stabilizationWindowSeconds` и `policies`. Эта статья содержит практические шаги, примеры кода и лучшие практики, чтобы ваши развертывания Kubernetes динамически адаптировались к изменяющимся нагрузкам, предотвращали избыточное выделение ресурсов и поддерживали высокую доступность.

24 просмотров

Практическое руководство по настройке горизонтального автомасштабирования подов (HPA) в Kubernetes

Kubernetes произвел революцию в том, как приложения развертываются, управляются и масштабируются. В основе его возможностей масштабирования лежит Horizontal Pod Autoscaler (HPA) — мощный механизм, который автоматически изменяет количество реплик подов в развертывании, контроллере репликации, ReplicaSet или StatefulSet на основе наблюдаемой утилизации ЦП или других выбранных метрик. Хотя HPA предлагает огромные преимущества для обработки колеблющихся нагрузок, его истинный потенциал раскрывается благодаря тщательной настройке и оптимизации.

Это руководство посвящено практическим аспектам настройки и оптимизации Kubernetes Horizontal Pod Autoscaler. Мы рассмотрим фундаментальные концепции, основные параметры, стратегии продвинутой настройки и лучшие практики, чтобы гарантировать, что ваши приложения могут эффективно адаптироваться к спросу, поддерживать производительность при различных нагрузках и оптимизировать затраты на инфраструктуру. К концу этой статьи у вас будет твердое понимание того, как максимально использовать HPA.

Понимание Horizontal Pod Autoscaler (HPA)

HPA автоматически масштабирует количество подов в вашем приложении вверх или вниз в соответствии с текущим спросом. Он постоянно отслеживает указанные метрики и сравнивает их с целевыми значениями. Если наблюдаемая метрика превышает цель, HPA инициирует событие увеличения масштаба (scale-up); если она падает ниже, он запускает уменьшение масштаба (scale-down). Эта динамическая корректировка гарантирует, что у вашего приложения достаточно ресурсов для оптимальной работы без избыточного выделения.

HPA может масштабироваться на основе:

  • Ресурсные метрики (Resource Metrics): В основном утилизация ЦП и утилизация памяти (доступны через API metrics.k8s.io, обычно предоставляются Kubernetes Metrics Server).
  • Пользовательские метрики (Custom Metrics): Метрики, специфичные для приложения, предоставляемые через API custom.metrics.k8s.io (например, запросы в секунду, глубина очереди, активные соединения). Обычно для этого требуется адаптер, такой как prometheus-adapter.
  • Внешние метрики (External Metrics): Метрики, поступающие из источников за пределами кластера и предоставляемые через API external.metrics.k8s.io (например, размер очереди Google Cloud Pub/Sub, длина очереди AWS SQS). Они также требуют сервер API пользовательских метрик, способный извлекать внешние метрики.

Предварительные требования для эффективной настройки HPA

Прежде чем углубляться в конфигурации HPA, убедитесь, что соблюдены следующие основополагающие элементы:

1. Определение точных запросов и лимитов ресурсов

Это, пожалуй, самое важное предварительное условие. HPA в значительной степени полагается на правильно определенные запросы на ЦП и память для расчета процентов утилизации. Если для пода не определены запросы на ЦП, HPA не сможет рассчитать его утилизацию ЦП, что делает масштабирование на основе ЦП невозможным.

  • Запросы (Requests): Определяют минимально гарантированные ресурсы для ваших контейнеров. HPA использует эти значения для определения целевой утилизации на один под.
  • Лимиты (Limits): Определяют максимальные ресурсы, которые может потребить контейнер. Лимиты не позволяют одному поду потреблять чрезмерное количество ресурсов и влиять на другие поды на том же узле.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image:latest
        resources:
          requests:
            cpu: "200m"  # 20% одного ядра ЦП
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

2. Установка Kubernetes Metrics Server

Чтобы HPA мог использовать метрики утилизации ЦП и памяти, в вашем кластере должен быть установлен Kubernetes Metrics Server. Он собирает ресурсные метрики с Kubelet и предоставляет их через API metrics.k8s.io.

3. Наблюдаемость приложения

Для пользовательских или внешних метрик ваше приложение должно предоставлять соответствующие метрики (например, через конечную точку Prometheus), и вам потребуется способ сбора и предоставления этих метрик API Kubernetes, обычно с использованием адаптера Prometheus или сервера API пользовательских метрик.

Настройка HPA: Основные параметры

Рассмотрим базовую структуру манифеста HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Ключевые параметры:

  • scaleTargetRef: Определяет целевой ресурс (например, Deployment), который будет масштабировать HPA. Укажите его apiVersion, kind и name.
  • minReplicas: Минимальное количество подов, до которого HPA будет уменьшать масштаб. Рекомендуется устанавливать его равным как минимум 1 или 2 для обеспечения высокой доступности даже при нулевой нагрузке.
  • maxReplicas: Максимальное количество подов, до которого HPA будет увеличивать масштаб. Это служит защитой от бесконтрольного масштабирования и ограничивает затраты.
  • metrics: Массив, определяющий метрики, которые должен отслеживать HPA.
    • type: Может быть Resource, Pods, Object или External.
    • resource.name: Для типа Resource указывает cpu или memory.
    • target.type: Для типа Resource — Utilization (процент от запрошенного ресурса) или AverageValue (абсолютное значение).
    • averageUtilization: Для типа Utilization — целевой процент. HPA рассчитывает желаемое количество подов на основе формулы current_utilization / target_utilization * current_pods_count.

Настройка HPA для отзывчивости и стабильности

Помимо базовой настройки, HPA предлагает расширенные параметры настройки, особенно с версией autoscaling/v2 (или v2beta2 в более старых версиях), для более гранулярного управления поведением масштабирования.

1. Целевые значения ЦП и памяти (averageUtilization / averageValue)

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

  • Как определить оптимальные цели: Тестирование нагрузки и профилирование — ваши лучшие друзья. Постепенно увеличивайте нагрузку на приложение, отслеживая использование ресурсов и метрики производительности (задержка, частота ошибок). Определите утилизацию ЦП/памяти, при которой производительность вашего приложения начинает ухудшаться. Установите цель HPA ниже этого порога, обычно в диапазоне 60–80% для ЦП.
  • Баланс: Стремитесь к цели, которая оставляет достаточный запас для неожиданных скачков, но не настолько низкий, чтобы у вас постоянно было избыточное выделение ресурсов.

2. Поведение масштабирования (поле behavior)

Поле behavior, появившееся в HPA autoscaling/v2, обеспечивает детальный контроль над событиями увеличения и уменьшения масштаба, предотвращая «мерцание» (быстрые циклы увеличения и уменьшения масштаба).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60 # Ждать 60 с перед повторным увеличением масштаба
      policies:
      - type: Pods
        value: 4
        periodSeconds: 15 # Добавлять максимум 4 пода каждые 15 секунд
      - type: Percent
        value: 100
        periodSeconds: 15 # Или удваивать текущее количество подов каждые 15 секунд (в зависимости от того, что менее ограничивает)
    scaleDown:
      stabilizationWindowSeconds: 300 # Ждать 5 минут перед уменьшением масштаба
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60 # Удалять максимум 50% подов каждые 60 секунд
      selectPolicy: Max # Выбрать политику, которая допускает 'наибольшее' количество подов (наименее агрессивное уменьшение)

Конфигурация scaleUp:

  • stabilizationWindowSeconds: Это предотвращает быстрые циклы увеличения и уменьшения масштаба (колебания). HPA учитывает метрики из этого окна при увеличении масштаба, гарантируя, что он увеличит масштаб только в том случае, если более высокое значение метрики сохраняется. Типичное значение — 30–60 секунд.
  • policies: Определяет, как добавляются поды во время события увеличения масштаба. Вы можете определить несколько политик, и HPA будет использовать ту, которая позволяет добавить наибольшее количество подов (наиболее агрессивное увеличение масштаба).
    • type: Pods: Увеличивает масштаб на фиксированное количество подов. value указывает добавляемое количество подов. periodSeconds определяет временное окно, в течение которого применяется эта политика.
    • type: Percent: Увеличивает масштаб на процент от текущего количества подов. value — это процент.

Конфигурация scaleDown:

  • stabilizationWindowSeconds: Более критично для scaleDown, оно указывает, как долго HPA должен наблюдать метрики ниже целевого значения, прежде чем рассмотреть возможность уменьшения масштаба. Более длительное окно (например, 300–600 секунд) предотвращает преждевременное уменьшение масштаба во время временных спадов, избегая «холодных стартов» и падения производительности. Это ключевая настройка для стабильных сред.
  • policies: Аналогично scaleUp, определяет, как удаляются поды. HPA использует политику, которая приводит к наименьшему количеству подов (наиболее агрессивное уменьшение масштаба), если selectPolicy равно Min, или политику, которая приводит к наибольшему количеству подов, если selectPolicy равно Max.
    • type: Pods: Удаляет фиксированное количество подов.
    • type: Percent: Удаляет процент от текущих подов.

  • selectPolicy: Определяет, какая политика применяется, если определено несколько политик scaleDown. Min является значением по умолчанию и обычно рекомендуется для более консервативного уменьшения масштаба; Max выберет политику, которая приводит к наибольшему количеству подов (наименее агрессивное уменьшение масштаба).

  • Внимание: Будьте осторожны с агрессивными политиками scaleDown или короткими значениями stabilizationWindowSeconds для scaleDown. Если ваше приложение имеет длительное время инициализации или обрабатывает соединения с сохранением состояния, быстрое уменьшение масштаба может привести к перебоям в обслуживании или увеличению задержки для пользователей.

Расширенные метрики и стратегии HPA

Хотя ЦП и память являются распространенными, многие приложения лучше масштабируются на основе пользовательских или внешних метрик, которые отражают их фактическую рабочую нагрузку.

1. Пользовательские метрики

Используйте пользовательские метрики, когда ЦП/память не являются прямым показателем нагрузки или узкого места производительности вашего приложения. Примеры: HTTP-запросы в секунду (QPS), активные соединения, длина очереди сообщений, отставание пакетной задачи.

Для использования пользовательских метрик:
1. Ваше приложение должно предоставлять эти метрики (например, через экспортер Prometheus).
2. Разверните адаптер пользовательских метрик (например, prometheus-adapter), который может извлекать эти метрики и предоставлять их через API custom.metrics.k8s.io.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa-qps
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 15
  metrics:
  - type: Pods # Или Object, если метрика относится ко всему развертыванию
    pods:
      metric:
        name: http_requests_per_second # Имя метрики, предоставляемой вашим приложением/адаптером
      target:
        type: AverageValue
        averageValue: "10k" # Цель: 10 000 запросов в секунду на под

2. Внешние метрики

Внешние метрики полезны, когда рабочая нагрузка вашего приложения определяется внешней системой, не работающей непосредственно в Kubernetes. Примеры: глубина очереди AWS SQS, отставание топика Kafka, отставание подписки Pub/Sub.

Для использования внешних метрик:
1. Вам нужен сервер API пользовательских метрик, который может извлекать метрики из вашей внешней системы (например, специальный адаптер для AWS CloudWatch или GCP Monitoring).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-worker-hpa-sqs
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-worker
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: aws_sqs_queue_messages_visible # Имя метрики из вашего внешнего источника
        selector:
          matchLabels:
            queue: my-queue-name
      target:
        type: AverageValue
        averageValue: "100" # Цель: 100 видимых сообщений в очереди на под

3. Несколько метрик

HPA может быть настроен для одновременного мониторинга нескольких метрик. Когда указано несколько метрик, HPA независимо вычисляет желаемое количество реплик для каждой метрики, а затем выбирает наибольшее из этих желаемых количеств реплик. Это гарантирует, что приложение будет масштабироваться в достаточной степени для всех наблюдаемых измерений нагрузки.

# ... (стандартные элементы HPA)
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "10k"

Мониторинг и проверка

Эффективная настройка HPA — это итеративный процесс, требующий постоянного мониторинга и проверки:

  • Наблюдайте события HPA: Используйте kubectl describe hpa <hpa-name>, чтобы просмотреть статус HPA, события и решения о масштабировании. Это дает ценную информацию о том, почему HPA увеличил или уменьшил масштаб.
  • Отслеживайте метрики и реплики: Используйте свой стек наблюдаемости (например, Prometheus, Grafana) для визуализации использования ресурсов вашего приложения (ЦП, память), пользовательских/внешних метрик и фактического количества реплик подов с течением времени. Соотнесите это с изменениями входящей нагрузки.
  • Тестирование нагрузки: Моделируйте ожидаемые и пиковые нагрузки, чтобы проверить отзывчивость HPA и убедиться, что ваше приложение ведет себя ожидаемым образом под нагрузкой. Настройте параметры HPA на основе этих тестов.

Лучшие практики настройки HPA

  • Начните с четко определенных запросов/лимитов ресурсов: Они являются основой точного HPA на основе ресурсов. Без них HPA не может эффективно работать для ЦП/памяти.
  • Установите реалистичные minReplicas и maxReplicas: minReplicas обеспечивает базовый уровень доступности, а maxReplicas действует как защитная сетка от чрезмерных затрат и исчерпания ресурсов.
  • Постепенно настраивайте целевую утилизацию: Начните с несколько консервативной цели по ЦП (например, 60–70%) и итерируйте. Не стремитесь к 100% утилизации, так как это не оставляет запаса для задержек или пиков обработки.
  • Используйте stabilizationWindowSeconds: Важно для предотвращения быстрых колебаний масштабирования. Используйте более длительное окно для scaleDown (например, 5–10 минут), чем для scaleUp (например, 1–2 минуты), для обеспечения стабильности.
  • Приоритизируйте метрики, специфичные для приложения: Если ЦП или память не коррелируют напрямую с узкими местами производительности вашего приложения, используйте пользовательские или внешние метрики для более точного и эффективного масштабирования.
  • Мониторинг, Тестирование, Итерация: Настройка HPA — это не одноразовая установка. Поведение приложения, шаблоны трафика и базовая инфраструктура могут меняться. Регулярно проверяйте производительность HPA и при необходимости корректируйте настройки.
  • Понимание характеристик масштабирования вашего приложения: Масштабируется ли оно линейно с запросами? Имеет ли оно длительное время запуска? Является ли оно stateful? Эти характеристики влияют на вашу стратегию HPA.

Заключение

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

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