Привет, Хабр!

Автоскейлинг в Kubernetes — это процесс автоматического увеличения или уменьшения количества ресурсов, выделенных для приложения, в зависимости от текущей нагрузки. Он позволяет приложениям масштабироваться горизонтально или вертикально (изменяя ресурсы на уровне подов), а также управлять количеством нод в кластере.

В статье рассмотрим три основных метода автоскейлинга в Kubernetes: Horizontal pod autoscaler (HPA), Vertical pod autoscaler (VPA) и Cluster autoscaler (CA).

HPA

HPA автоматически регулирует количество подов в приложении в зависимости от текущей нагрузки.

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

Основные шаги работы:

  1. Сбор метрик: HPA собирает метрики из Kubernetes Metrics API. Это могут быть стандартные метрики или кастомные метрики, определенные юзерами.

  2. Сравнение с целевыми значениями: собранные метрики сравниваются с целевыми значениями, которые указаны в конфигурации HPA.

  3. Решение о скейлинге: если текущие значения метрик отличаются от целевых, HPA принимает решение о необходимости увеличения или уменьшения количества подов.

  4. Изменение количества подов: HPA обновляет количество подов в контроллере (например, Deployment), что приводит к созданию или удалению подов для достижения целевых значений метрик.

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

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

  • Минимальное и максимальное количество подов: определяются границы, в пределах которых HPA может изменять количество подов.

  • Период проверки: задает интервал, через который HPA будет проверять текущие метрики (по дефолту 30 секунд).

Пример конфигурации HPA для приложения, использующего метрику CPU:

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

HPA будет поддерживать использование CPU на уровне 50%. Если среднее использование CPU превышает или снижается ниже этого значения, HPA увеличит или уменьшит количество подов в диапазоне от 2 до 10.

HPA суперски подходит для работы с CPU и памятью, однако поддержка кастомных метрик может требовать доп. настроек.

VPA

VPA автоматически регулирует запросы на ресурсы для подов, основываясь на их текущем и историческом использовании. VPA оптимизирует ресурсы внутри кластера, уменьшая вероятность перерасхода или недооценки ресурсов.

VPA мониторит использование ресурсов подами и регулирует их запросы, чтобы соответствовать текущим потребностям. Основная цель VPA — обеспечить подам достаточное количество ресурсов для выполнения их задач, избегая при этом избыточных резервирований.

Основные компоненты VPA:

  1. Recommender: анализирует текущие и исторические данные использования ресурсов подами и предоставляет рекомендации по их настройке.

  2. Updater: при необходимости перезапускает поды, чтобы применить новые запросы ресурсов.

  3. Admission Plugin: применяет рекомендованные запросы на ресурсы при создании новых подов или при изменении существующих.

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

Пример конфигурации:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: myapp-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind:       Deployment
    name:       myapp
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: "myapp-container"
      minAllowed:
        cpu: "200m"
        memory: "256Mi"
      maxAllowed:
        cpu: "2"
        memory: "4Gi"

VPA настроен для Deployment myapp. Политика обновления установлена в режим Auto, что позволяет автоматическую корректировку ресурсов.

VPA и HPA не рекомендуется использовать одновременно на одних и тех же подах, т.к они могут конфликтовать друг с другом.

Необходимо учитывать, что перезапуски подов могут временно снижать доступность приложения. Для того, чтобы это влияние было минимальным, нужно настраивать политики обновления и учитывать характеристики приложений при выборе параметров VPA.

Пример настройки для минимизации перезапусков:

spec:
  updatePolicy:
    updateMode: "Off" # полностью отключить автоматическое обновление

CA

CA автоматически регулирует количество нод в кластере в зависимости от потребностей в ресурсах. CA добавляет ноды, когда текущие ресурсы недостаточны для запуска новых подов, и удаляет ноды, когда их ресурсы недоиспользуются.

CA мониторит состояние подов и нод в кластере, принимая решения на основе следующих правил:

  1. Добавление нод: если есть поды, которые не могут быть запущены из-за недостатка ресурсов, CA увеличивает размер кластера, добавляя новые ноды.

  2. Удаление нод: если ноды недоиспользуются (например, все поды на ноде могут быть перенесены на другие ноды), CA уменьшает размер кластера, удаляя такие ноды.

CA поддерживает интеграцию с различными облачными провайдерами.

Например, для интеграции с AWS необходимо настроить IAM роли, задать типы экземпляров и регионы:

apiVersion: autoscaling/v1
kind: ClusterAutoscaler
metadata:
  name: cluster-autoscaler
spec:
  nodeSelector:
    aws-type: spot
  resources:
    requests:
      cpu: 100m
      memory: 300Mi
  awsRegion: us-west-2
  awsAccessKeyID: YOUR_AWS_ACCESS_KEY_ID
  awsSecretAccessKey: YOUR_AWS_SECRET_ACCESS_KEY

Для настройки CA на GCP необходимо указать проект, зону и типы машин:

apiVersion: autoscaling/v1
kind: ClusterAutoscaler
metadata:
  name: cluster-autoscaler
spec:
  nodeSelector:
    cloud.google.com/gke-nodepool: default-pool
  resources:
    requests:
      cpu: 100m
      memory: 300Mi
  gcpProjectID: YOUR_GCP_PROJECT_ID
  gcpZone: us-central1-a
  gcpServiceAccountJSON: YOUR_GCP_SERVICE_ACCOUNT_JSON

Для интеграции с Azure необходимо нужно задать параметры подписки и типы виртуальных машин:

apiVersion: autoscaling/v1
kind: ClusterAutoscaler
metadata:
  name: cluster-autoscaler
spec:
  nodeSelector:
    kubernetes.azure.com/agentpool: nodepool1
  resources:
    requests:
      cpu: 100m
      memory: 300Mi
  azureSubscriptionID: YOUR_AZURE_SUBSCRIPTION_ID
  azureResourceGroup: YOUR_AZURE_RESOURCE_GROUP
  azureVMType: Standard_DS2_v2

Сравним способы

Критерий

Horizontal Pod Autoscaler (HPA)

Vertical Pod Autoscaler (VPA)

Cluster Autoscaler (CA)

Основное назначение

Масштабирование подов горизонтально

Регулировка ресурсов подов

Масштабирование нод в кластере

Тип масштабирования

Горизонтальное (добавление/удаление подов)

Вертикальное (изменение запросов ресурсов подов)

Масштабирование нод (добавление/удаление нод)

Метрики для принятия решений

CPU, память, кастомные метрики

CPU, память

Состояние подов и нод, используемые ресурсы

Периодичность проверки

30 секунд (по дефолту)

10 секунд (по дефолту)

Каждые 10 секунд

Примеры использования

Веб-приложения с переменной нагрузкой, обработка данных

Приложения с изменяющимися требованиями к ресурсам

Облачные кластеры с динамическими нагрузками

Ограничения

Конфликты с VPA, задержки в реакциях

Необходимость перезапуска подов, несовместимость с HPA

Задержки в масштабировании, зависимость от облака


Статья подготовлена в преддверии старта курса "Инфраструктурная платформа на основе Kubernetes". Узнать о курсе подробнее можно по ссылке.

Комментарии (1)


  1. MrAlone
    25.06.2024 09:11

    У HPA поменялась версия апи, теперь
    apiVersion: autoscaling/v2

    Для подов, где запускается несколько контейнеров, лучше брать значение для конкретного контейнера, иначе скэйлинг не сработает. Например мы поднимаем под с апликачкой и opentelemetry в виде sidecar, в таком случае HPA не сможет корректно определить какую-нибудь загрузку по ЦПУ и нужно будет явно указывать контейнер, например:

    type: ContainerResource containerResource: name: cpu container: application target: type: Utilization averageUtilization: 60