Истории успеха наших клиентов — лучшие проекты
Вход/ Регистрация
На главную
25eb9e0a-a5a8-472a-ace7-940b8bd2adf0
Облачные сервисы

Автомасштабирование Kubernetes

Автомасштабирование в Kubernetes позволяет гибко управлять ресурсами кластера, автоматически добавляя или удаляя ноды и поды в зависимости от нагрузки.

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

Включение автомасштабирования при создании кластера

Для включения автомасштабирования на этапе создания кластера, необходимо выбрать опцию «Автомасштабирование» в разделе «Конфигурация воркер-нод».

Scr 20250820 Kkhn

Минимальное количество нод на этапе создания кластера — 1.

Включение автомасштабирования для существующего кластера

Если кластер уже создан, включить автомасштабирование можно следующим образом:

  1. Перейдите на вкладку «Ресурсы».

  2. Выберите «Редактировать группу».

Image1

В появившемся меню включите опцию автомасштабирования для группы.

Scr 20250820 Kkvg

Минимальное количество нод — 0.

Принцип работы автомасштабирования

Для управления созданием и удалением нод используются следующие параметры:

    

Параметр

Описание

scale-down-unneeded-time

Время, в течение которого нода должна простаивать перед удалением (в данном случае - 5 минут).

max-scale-down-parallelism

Максимальное количество нод, которые могут быть удалены одновременно (в данном случае - 1).

provisioning-request-max-backoff-time

Максимальное время ожидания при создании ноды (3 минуты).

max-inactivity

Максимальное время бездействия, после которого может начаться уменьшение количества нод (3 минуты).

scale-down-delay-after-add

Время задержки после добавления ноды перед началом уменьшения (3 минуты).

max-node-provision-time

Максимальное время для создания новой ноды (3 минуты).

Эти параметры определяют, как быстро добавляются или удаляются ноды в зависимости от текущей нагрузки. Например, если нагрузка снижается и нода простаивает более 5 минут, она будет удалена. Однако удаление нод происходит постепенно, чтобы не вызвать резкое уменьшение ресурсов. Если нагрузка увеличивается, новые ноды добавляются, но этот процесс также контролируется, чтобы избежать долгих задержек — на это отводится максимум 3 минуты. Таким образом, автомасштабирование стремится поддерживать баланс между доступностью ресурсов и их экономичным использованием.

Требования к кластеру

Максимальное количество нод в группе не может превышать максимально допустимое количество воркер-нод в кластере. Например, если для всего кластера установлено ограничение в 100 нод, а одна из групп уже использует 30 нод, для новой группы можно установить максимум 70 нод.

Настройка ресурсов для подов

Автомасштабирование работает только в том случае, если в деплойменте указаны ресурсы requests и limits. Ниже приведен пример файла деплоймента:

    

Лимиты CPU измеряются в миллиядрах (m), где 1000m равняется одному ядру. Лимиты памяти измеряются в мебибайтах (Mi) или гибибайтах (Gi).

Настройка Horizontal Pod Autoscaler (HPA)

Horizontal Pod Autoscaler (HPA) используется для динамического изменения количества подов в зависимости от потребления ресурсов, таких как процессор или память. HPA масштабирует поды, чтобы поддерживать заданный уровень использования ресурсов и адаптироваться к изменяющимся условиям нагрузки. Ниже приведен пример манифеста HPA:

    

Подробное описание параметров HPA

  • 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:

    

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

Настройка горизонтального автомасштабирования подов на примере Nginx

Для демонстрации автомасштабирования подов на примере Nginx необходимо использовать объект HorizontalPodAutoscaler (HPA). HPA автоматически регулирует количество реплик подов в зависимости от потребления ресурсов. Пример файла HPA:

Файл hpa.yaml:

    

В данном примере HPA регулирует количество реплик пода nginx-deployment в зависимости от загрузки процессора, поддерживая ее на уровне 20%.

Настройка балансировщика нагрузки

Для правильного распределения нагрузки между подами рекомендуется использовать объект Service с типом LoadBalancer. Пример файла конфигурации сервиса:

Файл service.yaml:

    

Этот сервис обеспечивает доступ к подам, используя балансировку нагрузки по нескольким портам.

Применение настроек

Для применения YAML-файлов необходимо использовать команды:

    

Эти команды применят конфигурации деплоймента, HPA и балансировщика, создавая все необходимые компоненты для работы автомасштабирования.

Демонстрация увеличения количества нод под нагрузкой

Перед тем как приступить к генерации нагрузки, убедитесь, что все ресурсы успешно созданы и находятся в состоянии Running. Чтобы увидеть, как работает автомасштабирование, можно сгенерировать нагрузку на наш сервис. Для этого воспользуемся утилитой hey, которая отправляет HTTP-запросы для тестирования производительности:

Генерируем нагрузку:

    

Этот запрос будет генерировать нагрузку в течение 10 минут с 20 параллельными подключениями к сервису Nginx, что приведет к увеличению использования ресурсов и, как следствие, к масштабированию количества реплик деплоймента и, при необходимости, количества воркер-нод. Спустя некоторое время после запуска утилиты, вы можете увидеть, что количество нод увеличилось. Увидеть это можно в панели управления или выполнив команду:

    

Также количество подов увеличилось до 4, как описано в hpa.yaml:

    
Была ли статья полезна?
Ваша оценка очень важна