Event-driven масштабирование в Managed Kubernetes с помощью KEDA

Перед началом работы

1. Сгенерируйте ключи доступа для интеграции

1. Сгенерируйте ключи доступа Key ID и Key Secret для своего аккаунта.

2. Сохраните значения Key ID и Key Secret в надежном месте, чтобы использовать их при загрузке образов контейнеров и подключении к кластеру Managed Kubernetes.

2. Разверните ресурсы в облаке

1. Создайте подсеть для размещения кластера Managed Kubernetes.

2. Создайте SNAT-шлюз в той же зоне доступности, что и подсеть.

3. Создайте виртуальную машину с подсетью с публичным IP-адресом. Выберите ранее созданную подсеть для подключения.

3. Подготовьте окружение виртуальной машины

1. Подключитесь к виртуальной машине по SSH, используя соответствующий SSH-клиент.

2. Установите необходимые инструменты для работы с Managed Kubernetes:

   1. kubectl

   2. cloudlogin

3. Установите Git и клонируйте репозиторий демоприложения:

   1. Установите Git для ОС на базе Ubuntu/Debian:

      sudo apt update && sudo apt install -y git
      
      

   2. Клонируйте репозиторий демоприложения:

      git clone https://gitverse.ru/sedg1l/keda-p2
      
      

4. Установите Docker:

   curl -fsSL https://get.docker.com -o get-docker.sh
   sudo sh ./get-docker.sh
   sudo groupadd docker
   sudo usermod -aG docker $USER
   newgrp docker
   
   

5. Установите Helm:

   curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
   chmod 700 get_helm.sh
   ./get_helm.sh
   
   

4. Создайте кластер Managed Kubernetes и подключитесь к нему

1. Создайте кластер в сервисе Managed Kubernetes:

   • Название: Cluster-keda.

   • Количество мастер-узлов: 1.

   • Конфигурация мастер-узла: 2 vCPU, 4 ГБ RAM.

   • Публичный IP: включен.

2. Создайте группу узлов

   • Гарантированная доля vCPU: 10%.

   • vCPU: 2.

   • RAM, ГБ: 4.

   • Количество узлов: 1.

3. Дождитесь окончания создания кластера.

4. Убедитесь, что в личном кабинете статус кластера — «Запущено».

5. Подключитесь к кластеру с управляющей виртуальной машины.

5. Создайте репозиторий Artifact Registry

6. Установите MongoDB через Helm

1. Установите MongoDB с помощью Helm:

   helm install mongodb oci://registry-1.docker.io/bitnamicharts/mongodb --set useStatefulSet=true --set auth.rootPassword=mongo
   
   

2. Проверьте статус развертывания MongoDB:

   kubectl get pods
   
   

3. Дождитесь, пока все поды MongoDB перейдут в состояние «Running».

7. Установите RabbitMQ через Helm

1. Установите RabbitMQ командой:

   helm install rabbitmq oci://registry-1.docker.io/bitnamicharts/rabbitmq --set auth.username=user --set auth.password=P@ssw0rd
   
   

2. Проверьте состояние подов RabbitMQ:

   kubectl get pods
   
   

3. Дождитесь, пока все поды очереди RabbitMQ перейдут в состояние «Running».

8. Установите KEDA через Helm

1. Добавьте репозиторий Helm и обновите его:

   helm repo add kedacore https://kedacore.github.io/charts
   helm repo update
   
   

2. Установите KEDA в отдельное пространство keda:

   helm install keda kedacore/keda --namespace keda --create-namespace
   
   

3. Проверьте статус подов KEDA:

   kubectl get pods -n keda
   
   

4. Дождитесь, пока все поды KEDA перейдут в состояние «Running».

9. Загрузите образы контейнеров в приватный реестр Artifact Registry

1. Перейдите в папку репозитория приложения:

   cd $HOME/keda-p2
   
   

2. Откройте файл build.sh в удобном редакторе.

3. Укажите URI вашего приватного реестра и ключи доступа к облаку в переменных в начале скрипта:

   • <REPO> — адрес реестра Artifact Registry.

   • <LOGIN> — Key ID учетной записи.

   • <PASSWORD> — Secret Key учетной записи.

4. Сделайте скрипт исполняемым и выполните его:

   chmod +x $HOME/keda-p2/build-images.sh
   $HOME/keda-p2/build-images.sh
   
   

   Скрипт выполнит аутентификацию с помощью ключей доступа в Artifact Registry, соберет образы контейнеров через Docker Engine и загрузит их в указанный реестр.

10. Разверните приложение в Managed Kubernetes

1. Примените манифесты:

   kubectl apply -f $HOME/keda-p2/deploy/
   
   

2. Ознакомьтесь со схемой работы приложения:

   

   • При отправке POST-запроса на http://complex-app-service/send?name=<item-name>&content=<content> сервис complex-app отправляет сообщение с параметрами name и content в формате JSON в очередь RabbitMQ.

   • Ресурс ScaledJob периодически опрашивает очередь RabbitMQ. Когда в очередь приходит новое сообщение, ScaledJob создает новый Kubernetes Job с именем processor-job.

   • Ресурс processor-job извлекает сообщение, записывает его в MongoDB в формате JSON (name и content), после чего засыпает на 20 секунд.

   • Функция sleep имитирует, что processor-job обрабатывает какой-то «тяжелый» файл. Например, конвертирует видео.

   • Если бы вы масштабировали Deployment с помощью ресурса HPA, то реализовать описанное выше масштабирование было бы невозможно, так как нам необходимо масштабировать ресурс не на основании метрик утилизации ресурсов, а на основании событий.

3. Проверьте, что все необходимые поды созданы и работают.

11. Проверьте работу автомасштабирования KEDA

1. Создайте тестовый под curl для взаимодействия с приложением:

   kubectl run -it --rm curl-pod --image=curlimages/curl -- /bin/sh
   
   

2. Внутри curl-pod отправьте несколько POST-запросов на сервис для генерации событий:

   curl -X POST "http://complex-app-keda-service/send?name=record1&content=content1"
   curl -X POST "http://complex-app-keda-service/send?name=record2&content=content2"
   curl -X POST "http://complex-app-keda-service/send?name=record3&content=content3"
   curl -X POST "http://complex-app-keda-service/send?name=record4&content=content4"
   curl -X POST "http://complex-app-keda-service/send?name=record5&content=content5"
   
   

3. Проверьте, что данные были добавлены в MongoDB:

   curl "http://complex-app-keda-service/data"
   
   

   Job-ресурсам потребуется некоторое время на запуск и выполнение, поэтому записи могут появиться в течение минуты.

4. Выйдите из curl-пода командой:

   exit
   
   

5. Проверьте количество созданных Job:

   kubectl get jobs
   
   

   Убедитесь, что для каждого события KEDA запустила отдельный Job, реализуя event-driven масштабирование обработки.

Что дальше