Привет, Хабр!
Автоскейлинг в Kubernetes — это процесс автоматического увеличения или уменьшения количества ресурсов, выделенных для приложения, в зависимости от текущей нагрузки. Он позволяет приложениям масштабироваться горизонтально или вертикально (изменяя ресурсы на уровне подов), а также управлять количеством нод в кластере.
В статье рассмотрим три основных метода автоскейлинга в Kubernetes: Horizontal pod autoscaler (HPA), Vertical pod autoscaler (VPA) и Cluster autoscaler (CA).
HPA
HPA автоматически регулирует количество подов в приложении в зависимости от текущей нагрузки.
HPA основывается на метриках использования ресурсов, таких как CPU и память. Он следит за этими метриками и, если они выходят за установленные пределы, увеличивает или уменьшает количество подов в вашем приложении. HPA функционирует как контроллер, который периодически проверяет текущие метрики и сравнивает их с целевыми значениями, заданными в конфигурации. Если метрики отклоняются от целевых значений, HPA вносит изменения в количество подов.
Основные шаги работы:
Сбор метрик: HPA собирает метрики из Kubernetes Metrics API. Это могут быть стандартные метрики или кастомные метрики, определенные юзерами.
Сравнение с целевыми значениями: собранные метрики сравниваются с целевыми значениями, которые указаны в конфигурации HPA.
Решение о скейлинге: если текущие значения метрик отличаются от целевых, HPA принимает решение о необходимости увеличения или уменьшения количества подов.
Изменение количества подов: 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:
Recommender: анализирует текущие и исторические данные использования ресурсов подами и предоставляет рекомендации по их настройке.
Updater: при необходимости перезапускает поды, чтобы применить новые запросы ресурсов.
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 мониторит состояние подов и нод в кластере, принимая решения на основе следующих правил:
Добавление нод: если есть поды, которые не могут быть запущены из-за недостатка ресурсов, CA увеличивает размер кластера, добавляя новые ноды.
Удаление нод: если ноды недоиспользуются (например, все поды на ноде могут быть перенесены на другие ноды), 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". Узнать о курсе подробнее можно по ссылке.
MrAlone
У HPA поменялась версия апи, теперь
apiVersion: autoscaling/v2
Для подов, где запускается несколько контейнеров, лучше брать значение для конкретного контейнера, иначе скэйлинг не сработает. Например мы поднимаем под с апликачкой и opentelemetry в виде sidecar, в таком случае HPA не сможет корректно определить какую-нибудь загрузку по ЦПУ и нужно будет явно указывать контейнер, например:
type: ContainerResource containerResource: name: cpu container: application target: type: Utilization averageUtilization: 60