Автоскейлинг в Kubernetes: HPA, VPA и Cluster Autoscaler

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

Автоскейлинг в 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

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

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