Автомасштабирование в Kubernetes позволяет гибко управлять ресурсами кластера, автоматически добавляя или удаляя ноды и поды в зависимости от нагрузки.
Опция доступна только для кластеров, созданных после 8 ноября 2024 года. Для кластеров, созданных ранее, данная возможность недоступна, даже при настройке через панель управления.
Для включения автомасштабирования на этапе создания кластера, необходимо выбрать опцию «Автомасштабирование» в разделе «Конфигурация воркер-нод».
Если кластер уже создан, включить автомасштабирование можно следующим образом:
Перейдите на вкладку «Ресурсы».
Выберите «Редактировать группу».
В появившемся меню включите опцию автомасштабирования для группы.
Для управления созданием и удалением нод используются следующие параметры:
--scale-down-unneeded-time 5m0s --max-scale-down-parallelism 1 --provisioning-request-max-backoff-time 3m0s --max-inactivity 3m0s --scale-down-delay-after-add 3m0s --max-node-provision-time 3m0s
Параметр |
Описание |
|
Время, в течение которого нода должна простаивать перед удалением (в данном случае - 5 минут). |
|
Максимальное количество нод, которые могут быть удалены одновременно (в данном случае - 1). |
|
Максимальное время ожидания при создании ноды (3 минуты). |
|
Максимальное время бездействия, после которого может начаться уменьшение количества нод (3 минуты). |
|
Время задержки после добавления ноды перед началом уменьшения (3 минуты). |
|
Максимальное время для создания новой ноды (3 минуты). |
Эти параметры определяют, как быстро добавляются или удаляются ноды в зависимости от текущей нагрузки. Например, если нагрузка снижается и нода простаивает более 5 минут, она будет удалена. Однако удаление нод происходит постепенно, чтобы не вызвать резкое уменьшение ресурсов. Если нагрузка увеличивается, новые ноды добавляются, но этот процесс также контролируется, чтобы избежать долгих задержек — на это отводится максимум 3 минуты. Таким образом, автомасштабирование стремится поддерживать баланс между доступностью ресурсов и их экономичным использованием.
Автомасштабирование работает только в том случае, если в деплойменте указаны ресурсы requests
и limits
. Ниже приведен пример файла деплоймента:
apiVersion: apps/v1
kind: Deployment
metadata:
name: example-deployment
spec:
selector:
matchLabels:
app: example
template:
metadata:
labels:
app: example
spec:
containers:
- name: example-container
image: example-image
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
cpu: "400m"
memory: "512Mi"
Лимиты CPU измеряются в милиядрах (m
), где 1000m равняется одному ядру. Лимиты памяти измеряются в мегабайтах (Mi
) или гигабайтах (Gi
).
Horizontal Pod Autoscaler (HPA) используется для динамического изменения количества подов в зависимости от потребления ресурсов, таких как процессор или память. HPA масштабирует поды, чтобы поддерживать заданный уровень использования ресурсов и адаптироваться к изменяющимся условиям нагрузки. Ниже приведен пример манифеста HPA:
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: example-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: example-deployment
minReplicas: 1
maxReplicas: 5
targetCPUUtilizationPercentage: 50
apiVersion
: Определяет версию API, используемую для создания ресурса. В данном случае это autoscaling/v1
.
kind
: Тип создаваемого ресурса, здесь - HorizontalPodAutoscaler
.
metadata
: Содержит информацию о метаданных, включая имя HPA (example-hpa
).
scaleTargetRef
: Указывает объект, который нужно масштабировать. Здесь задаются:
apiVersion
: Версия API ресурса, который будет масштабироваться.
kind
: Тип ресурса, который масштабируется, в данном случае - Deployment
.
name
: Имя ресурса, который необходимо масштабировать (example-deployment
).
minReplicas
: Минимальное количество реплик подов, которые должны поддерживаться, в данном случае - 1.
maxReplicas
: Максимальное количество реплик подов, до которого можно масштабироваться, здесь - 5.
targetCPUUtilizationPercentage
: Процент загрузки процессора, при котором будет изменяться количество реплик. В этом примере установлено значение 50, что означает, что количество реплик будет изменяться для поддержания среднего использования CPU на уровне 50%.
Для практического примера создадим деплоймент Nginx, который будет служить базой для настройки автомасштабирования:
Файл deployment.yaml
:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
cpu: "250m"
memory: "512Mi"
limits:
cpu: "500m"
memory: "1Gi"
Этот деплоймент создает под Nginx с установленными ограничениями на использование ресурсов, что необходимо для корректной работы HPA.
Для демонстрации автомасштабирования подов на примере Nginx необходимо использовать объект HorizontalPodAutoscaler
(HPA). HPA автоматически регулирует количество реплик подов в зависимости от потребления ресурсов. Пример файла HPA:
Файл hpa.yaml
:
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: nginx-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx-deployment
minReplicas: 1
maxReplicas: 4
targetCPUUtilizationPercentage: 20
В данном примере HPA регулирует количество реплик пода nginx-deployment
в зависимости от загрузки процессора, поддерживая ее на уровне 20%.
Для правильного распределения нагрузки между подами рекомендуется использовать объект Service
с типом LoadBalancer
. Пример файла конфигурации сервиса:
Файл service.yaml
:
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: LoadBalancer
Этот сервис обеспечивает доступ к подам, используя балансировку нагрузки по нескольким портам.
Для применения YAML-файлов необходимо использовать команды:
kubectl apply -f nginx-deployment.yaml
kubectl apply -f nginx-hpa.yaml
kubectl apply -f nginx-service.yaml
Эти команды применят конфигурации деплоймента, HPA и балансировщика, создавая все необходимые компоненты для работы автомасштабирования.
Перед тем как приступить к генерации нагрузки, убедитесь, что все ресурсы успешно созданы и находятся в состоянии Running
. Чтобы увидеть, как работает автомасштабирование, можно сгенерировать нагрузку на наш сервис. Для этого воспользуемся утилитой hey, которая отправляет HTTP-запросы для тестирования производительности:
Генерируем нагрузку:
hey -z 10m -c 20 http://ip_балансировщика
Этот запрос будет генерировать нагрузку в течение 10 минут с 20 параллельными подключениями к сервису Nginx, что приведет к увеличению использования ресурсов и, как следствие, к масштабированию количества реплик деплоймента и, при необходимости, количества воркер-нод. Спустя некоторое время после запуска утилиты, вы можете увидеть, что количество нод увеличилось. Увидеть это можно в панели управления или выполнив команду:
kubectl get nodes
Также количество подов увеличилось до 4, как описано в hpa.yaml
:
kubectl get pods