Автоскейлинг контроллеров Ingress в Kubernetes

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

В этом переводе рассказываем о том, как настроить автомасштабирование контроллера Ingress с использованием Prometheus, KEDA и Locust для генерации трафика.

Чтобы настроить автомасштабирование на основе входящих запросов, необходимо следующее:

  1. Метрики (например, количество запросов в секунду).

  2. Коллектор метрик (для хранения метрик).

  3. Автоскейлер (для обработки данных).

Источник
Источник

Давайте начнём с метрик.

Можно настроить nginx-ingress для отображения метрик Prometheus. Для подсчета количества активных запросов можно использовать nginx_connections_active.

Источник
Источник

Далее необходимо найти способ получения метрик. Как вы уже догадались, для этого можно установить Prometheus. Поскольку Nginx-ingress использует аннотации для Prometheus, я установил сервер без оператора Kubernetes.

$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
"prometheus-community" has been added to your repositories
$ helm install prometheus prometheus-community/prometheus
NAME: prometheus
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

Я использовал Locust для генерации трафика на Ingress, чтобы проверить, все ли работает гладко. Открыв приборную панель Prometheus, я проверил, что метрики увеличиваются по мере увеличения трафика на контроллере.

Источник
Источник

Последним пазлом стал автоскейлер. Я решил выбрать KEDA, потому что:

  1. Это автоскейлер с сервером метрик (поэтому мне не нужно устанавливать два разных инструмента).

  2. Он проще в настройке, чем адаптер Prometheus.

  3. Я могу использовать Horizontal Pod Autoscaler с PromQL.

Источник
Источник

После установки KEDA мне оставалось только создать объект ScaledObject, настроить источник метрик (Prometheus) и масштабировать подсистемы (с помощью запроса PromQL).

Источник
Источник

KEDA автоматически создает для меня HPA. Я повторил тесты с Locust и наблюдал, как увеличивается количество реплик по мере увеличения трафика на контроллере Nginx Ingress!

Источник
Источник

Можно ли распространить этот паттерн на любое другое приложение? Можно ли автомасштабировать все микросервисы по количеству поступающих запросов? 

Если они не предоставляют метрики, то ответ отрицательный. Однако существует обходной путь.

KEDA поставляется с HTTP-надстройкой для обеспечения масштабирования по протоколу HTTP. Как это работает? KEDA ижектит прокси sidecar в ваш pod, чтобы весь HTTP-трафик маршрутизировался первым. Затем он измеряет количество запросов и выдает метрики. Имея под рукой эти данные, можно запустить автоскейлер.

Источник
Источник

Однако KEDA — не единственный вариант. Можно установить Prometheus Adapter. Метрики будут поступать из Nginx в Prometheus, а затем адаптер сделает их доступными для Kubernetes. Оттуда они потребляются Horizontal Pod Autoscaler.

Источник
Источник

Лучше ли это, чем KEDA? Они похожи, поскольку оба должны запрашивать и буферизовать метрики из Prometheus. Однако KEDA является подключаемой, а Adapter работает исключительно с Prometheus.

Источник
Источник

Есть ли конкурент у KEDA?

Перспективный проект под названием Custom Pod Autoscaler призван сделать автоскейлер подключаемым. Однако проект в большей степени ориентирован на то, как эти поды должны масштабироваться (т.е. на алгоритм), а не на сбор метрик.

Эти ссылки могут быть полезными для дальнейшего изучения темы:

https://keda.sh/docs/2.10/scalers/prometheus/

https://sysdig.com/blog/kubernetes-hpa-prometheus/

https://github.com/nginxinc/nginx-prometheus-exporter#exported-metrics

https://learnk8s.io/scaling-celery-rabbitmq-kubernetes


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

  • Изучите тонкости установки и конфигурации production-ready кластера.

  • Разберетесь с механизмами стабильности, безопасности и отказоустойчивости.

  • Научитесь работать с масштабированием.

  • Разберёте стратегические задачи инфраструктуры.

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

Источник: https://habr.com/ru/companies/slurm/articles/764740/


Интересные статьи

Интересные статьи

В интервью с Марселем Ибраевым, CTO Слёрма и спикером курса «Kubernetes: Мега-поток» вспомнили работу в техподдержке и посмотрели в будущее k8s.Марсель рассказывает, как стал спикером и почему Kuberne...
Работаете с Kubernetes не первый год? Уже три раза роняли и поднимали продакшен-кластер? Пройдите тест и узнайте, насколько вы хороши в Kubernetes.
Привет, Хабр! Как и многие другие, в прошлом году мне пришлось внезапно мигрировать из тесного привычного офиса к себе домой. Я и раньше работал из дома, когда была такая...
Kubernetes API Server вылетел с ошибкой (OOMKilled) Прошло больше года с нашего [компании Pinterest] перехода на платформу Kubernetes. С тех пор мы разработали множество новых функц...
Команда Kubernetes as a Service в Mail.ru Cloud Solutions перевела контрольный список для запуска Redis внутри кластера Kubernetes. С ним стоит ознакомиться до того, как перейти к испол...