Автомасштабирование Kubernetes Pods для микросервисов

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

В Kubernetes планирование мощности кластера имеет решающее значение, чтобы избежать избыточного или недостаточного предоставления инфраструктуры. ИТ-администраторам необходим надежный и экономически эффективный способ поддержания работоспособности кластеров и стручков в условиях высокой нагрузки и автоматического масштабирования инфраструктуры в соответствии с требованиями к ресурсам.

Мы знаем, что Kubernetes поддерживает 3 различных типа автомасштабирования:

1. Vertical Pod Autoscaler (VPA). Увеличивает или уменьшает ограничения на ресурсы для стручка.
2. Horizontal Pod Autoscaler (HPA). Увеличивает или уменьшает количество экземпляров стручков.
3. Cluster Autoscaler (CA). Увеличивает или уменьшает количество узлов в пуле узлов, основываясь на расписании pod
планирования.

Я сосредоточусь на опциях Horizontal и Vertical, поскольку буду работать на уровне стручков, а не на уровне узлов.

Содержание

Настройка микросервиса в кластере Kubernetes:
Horizontal Pod Autoscaler (HPA)
Запуск автомасштабирования микросервиса путем применения нагрузки
Вертикальный автомасштабатор стручков
Противоречия, предостережения и проблемы при автомасштабировании

Настройка микросервиса в кластере Kubernetes:

Чтобы начать, давайте создадим REST API для развертывания в качестве микросервиса в контейнерах на Kubernetes. Для более глубокого рассмотрения этого вопроса мы можем сначала создать REST API – написанный на Go, как представлено ниже – который развертывает микросервис на Kubernetes. Сохраните приведенное ниже содержимое в файле с именем deployment.yml.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: microsvcmonirul
  namespace: monirul
spec:
selector:
   matchLabels:
     run: microsvcmonirul
replicas: 1
template:
   metadata:
  labels:
    run: microsvcmonirul
spec:
  containers:
  - name: microsvcmonirul
image: "monirul87/microsvcmonirul-1.0.3" ports:
- containerPort: 8080
         resources:
          requests:
            memory: "64Mi"
            cpu: "125m"
          limits:
            memory: "128Mi"
            cpu: "250m"
---
apiVersion: v1
kind: Service
metadata:
  name: microsvcmonirul
  namespace: monirul
  labels:
    run: microsvcmonirul
 spec: ports:
  - port: 8087
    targetPort: 8080
  selector:
    run: microsvcmonirul

Войти в полноэкранный режим Выход из полноэкранного режима

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

После завершения новая капсула запустится в кластере, как показано ниже.

Чтобы получить доступ к операционной деятельности микросервиса, откройте порты сервиса для публичного ip,

[root@kmaster microservice]# kubectl patch svc microsvcmonirul -n monirul -p '{"spec": {"type": "LoadBalancer", "externalIPs":["149.20.184.84"]}}'

Если я попытаюсь получить доступ к Golang REST API через браузер, он вернет ожидаемые результаты, как показано ниже.

Теперь, когда приложение работает как микросервис в кластере Kubernetes, давайте автомасштабируем мое приложение горизонтально в ответ на внезапное увеличение или уменьшение потребности в ресурсах.

Horizontal Pod Autoscaler (HPA)

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

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

Чтобы настроить контроллер HPA на управление рабочей нагрузкой, создайте объект HorizontalPodAutoscaler. Также HPA можно настроить с помощью подкоманды kubectl autoscale. Здесь я буду использовать подкоманду.

 apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: microsvcmonirul
  namespace: monirul
spec:
  maxReplicas: 10
  minReplicas: 1
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: microsvcmonirul
  targetCPUUtilizationPercentage: 50

Войти в полноэкранный режим Выйти из полноэкранного режима

С помощью следующей подкоманды создадим автомасштабируемое развертывание CPU,

[root@kmaster microservice]# kubectl autoscale deployment microsvcmonirul -n monirul --cpu-percent=50 --min=1 --max=4

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

Чтобы проверить состояние HPA с пространством имен monirul, выполните команду kubectl get hpa -n monirul, которая выдаст нам текущее и целевое потребление CPU. Первоначально в текущем состоянии может появиться ”неизвестное” значение, но со временем, по мере извлечения метрик, начнут появляться данные о сервере и процентном использовании.

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

kubectl describe hpa -n monirul

Приведенный выше микросервис, работающий в одной капсуле, имеет загрузку процессора менее 50%, поэтому нет необходимости в автомасштабировании капсул.

Запуск автомасштабирования микросервиса путем применения нагрузки

Чтобы создать нагрузку на приложение, мы используем образ BusyBox в контейнере, который будет запускать сценарий оболочки для бесконечных вызовов конечной точки REST, созданной в предыдущем микросервисе. BusyBox – это облегченный образ многих распространенных утилит Unix – например, wget – которые мы используем для создания нагрузки на микросервис. Этот стресс увеличивает потребление ресурсов на капсулах.

Сохраните следующую конфигурацию YAML в файл с именем infinite-calls-monirul.yaml. В нижней части кода команда wget вызывает REST API в бесконечном цикле while.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: infinite-calls-monirul
  namespace: monirul
  labels:

    app: infinite-calls-monirul
spec:
  replicas: 1
  selector:
    matchLabels:
      app: infinite-calls-monirul
template:
 done"
metadata:
  name: infinite-calls-monirul
  labels:
    app: infinite-calls-monirul
spec:
  containers:
  - name: infinite-calls-monirul
 image: busybox
command:
- /bin/sh
- -c
- "while true; do wget -q -O- http://149.20.184.84:8087/employee;

Войти в полноэкранный режим Выход из полноэкранного режима

Разверните эту конфигурацию YAML с помощью команды kubectl apply -f infinite-calls-monirul.yml.

Когда контейнер станет активным, запустите оболочку /bin/sh на контейнере с помощью команды kubectl exec -it <CONTAINER_NAME> sh, чтобы убедиться, что процесс запущен и бесконечно выполняет веб-запросы к конечной точке REST. Эти бесконечные вызовы создают нагрузку на приложение и приводят к увеличению процессорного времени контейнера, в котором размещено это веб-приложение.

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

Чтобы увидеть подробные события и активность HPA, выполните следующую команду и обратите внимание на выделенный раздел ниже для событий и триггеров автомасштабирования.

Вертикальный автомасштабатор стручков

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

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

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

VPA состоит из трех основных компонентов:

Рекомендатор: Контролирует использование ресурсов и вычисляет целевые значения. В режиме рекомендации VPA обновляет предложенные значения, но не завершает работу стручков.
Updater: Завершает работу стручков, которые были масштабированы с новыми ограничениями ресурсов. Поскольку Kubernetes не может изменить лимиты ресурсов запущенной капсулы, VPA завершает капсулы с устаревшими лимитами и заменяет их капсулами с обновленными значениями запросов и лимитов ресурсов.
Admission Controller: перехватывает запросы на создание стручков. Если стручок соответствует конфигурации VPA с режимом, не установленным на “off”, контроллер переписывает запрос, применяя рекомендуемые ресурсы к спецификации стручка.

Противоречия, предостережения и проблемы при автомасштабировании

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

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

Это может привести к неправильному распределению ресурсов и конфликтам.
Чтобы предотвратить такую ситуацию и продолжать использовать HPA и VPA параллельно, убедитесь, что они полагаются на разные метрики для автоматического масштабирования.