Автомасштабирование Kubernetes должно было быть простым

Автомасштабирование Kubernetes должно было быть простым. Несмотря на то, что одним из преимуществ Kubernetes является масштабирование, встроенная поддержка автомасштабирования в лучшем случае является базовой. Масштабирование возможно только в зависимости от потребления ЦП или памяти, для чего-либо более сложного требуются дополнительные инструменты, которые часто не являются тривиальными.

Команда Gimlet.io создала этот блог, чтобы показать распространенные варианты использования автомасштабирования:

* в зависимости от процессора * пользовательские метрики Prometheus * и длина очереди RabbitMQ

Кроме того, мы стремимся устранить различия между Horizontal Pod Autoscaler (HPA), адаптером Prometheus и KEDA.

Давайте приступим к делу?

Во-первых, о Horizontal Pod Autoscaler (HPA).

Во-первых, о Horizontal Pod Autoscaler (HPA)

Горизонтальное автомасштабирование Pod, сокращенно HPA, – это ресурс Kubernetes, который позволяет масштабировать приложение на основе использования ресурсов, таких как ЦП и память.

Если быть более точным, HPA – это средство автомасштабирования общего назначения, но по умолчанию для его масштабирования доступны только показатели ЦП и памяти.

Его источником данных является Kubernetes Metrics API, который, кстати, также поддерживает команду kubectl top и опирается на данные, предоставленные компонентом metrics-server. Этот компонент работает в вашем кластере и установлен по умолчанию на кластерах GKE, AKS, CIVO и k3s, но его необходимо установить вручную на многих других, таких как Digital Ocean, EKS и Linode.

Ресурс HPA довольно хорошо задокументирован в документации Kubernetes. Некоторая путаница возникает из-за того, что в блогах есть сообщения, демонстрирующие разные версии Kubernetes API: имейте в виду, что autoscaling/v2 не имеет обратной совместимости с v1!

Больше головной боли возникает, когда вы пытаетесь масштабировать метрики ресурсов, отличные от ЦП и памяти. Чтобы масштабировать модули, скажем, на основе количества HTTP-запросов или длины очереди, вам нужно сначала сделать так, чтобы Kubernetes API знал об этих показателях. К счастью, есть реализованные бэкэнды для метрик с открытым исходным кодом, и самым известным из них является адаптер Prometheus.

Адаптер Прометея

Адаптер Prometheus — это реализация API пользовательских метрик Kubernetes, которая предоставляет выбранные метрики Prometheus через API Kubernetes для масштабирования горизонтального модуля автомасштабирования (HPA).

По сути, вы настраиваете адаптер Prometheus для чтения желаемой метрики из Prometheus, и он передает ее в HPA для масштабирования. Это может быть частота HTTP-запросов, длина очереди RabbitMQ или любая метрика из Prometheus.

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

По сути, именно поэтому мы собрали вас сегодня здесь, чтобы поделиться своим опытом работы с альтернативным адаптером Prometheus под названием KEDA.

Итак, что такое KEDA и почему мы предпочитаем его?

КЕДА

KEDA – это оператор Kubernetes, который обрабатывает удобный пользовательский ресурс yaml, где вы можете определить свои потребности в масштабировании.

В KEDA вы создаете пользовательский ресурс ScaledObject с необходимой информацией о развертывании, которое вы хотите масштабировать, а затем определяете триггерное событие, которое может быть основано на использовании ЦП и памяти или на пользовательских показателях. В нем есть готовые триггеры практически для всего, что вы захотите масштабировать, со структурой yaml, которую, как мы думаем, API Kubernetes можно было бы создать в первую очередь.

KEDA делает две вещи:

* он предоставляет выбранные метрики API пользовательских метрик Kubernetes — так же, как Prometheus Adapter * и создает ресурс Horizontal Pod Autoscaler. В конечном итоге этот HPA выполняет масштабирование.

Теперь, когда у вас есть обзор, давайте сделаем еще один шаг и покажем, как вы можете использовать автомасштабирование с помощью KEDA!

Пример автоматического масштабирования на основе загрузки ЦП

Для автоматического масштабирования приложения с помощью KEDA необходимо определить ресурс ScaledObject.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cpu-based-scaledobject
  namespace: default
spec:
  minReplicaCount:  1                                 
  maxReplicaCount:  10
  scaleTargetRef:
    kind: Deployment
    name: test-app-deployment
  triggers:
  - type: cpu
    metricType: Utilization
    metadata:
      value: "50"

scaleTargetRef — это место, где вы ссылаетесь на свое развертывание, а triggers — это место, где вы определяете метрики и пороговые значения, которые запускают масштабирование.

В этом примере мы запускаем на основе использования ЦП, ScaledObject будет автоматически управлять количеством реплик и поддерживать максимальную загрузку ЦП на 50% для каждого модуля.

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

$ kubectl get scaledobject
NAME                    SCALETARGETKIND      SCALETARGETNAME      MIN   MAX   TRIGGERS  READY   ACTIVE
cpu-based-scaledobject  apps/v1.Deployment   test-app-deployment   2     10    cpu      True    True

Чтобы лучше понять, что происходит в фоновом режиме, вы можете просмотреть журналы модуля оператора keda, а также kubectl описать ресурс HPA, созданный KEDA.

Пример автоматического масштабирования на основе пользовательских показателей

Чтобы использовать специальные показатели, необходимо внести изменения в раздел triggers.

Пример масштабирования на основе пользовательских метрик Prometheus:

triggers:
- type: prometheus
  metadata:
    serverAddress: http://<prometheus-host>:9090
    metricName: http_requests_total # Note: name to identify the metric, generated value would be `prometheus-http_requests_total`
    query: sum(rate(http_requests_total{deployment="my-deployment"}[2m])) # Note: query must return a vector/scalar single element response
    threshold: '100.50'
    activationThreshold: '5.5'

Пример масштабирования на основе длины очереди RabbitMQ:

triggers:
- type: rabbitmq
  metadata:
    host: amqp://localhost:5672/vhost
    mode: QueueLength # QueueLength or MessageRate
    value: "100" # message backlog or publish/sec. target per instance
    queueName: testqueue

Посетите официальный сайт KEDA, чтобы увидеть все масштабирующие устройства.

Заключительные слова

Когда мы нашли KEDA, наши проблемы с адаптером Prometheus разрешились мгновенно. Простой процесс установки KEDA и готовые инструменты масштабирования позволили нам удовлетворить наши потребности в автоматическом масштабировании, а простой синтаксис yaml хорошо передает цель масштабирования.

Мы не только сами пользуемся KEDA, но и рекомендуем ее нашим клиентам и друзьям. Настолько, что мы интегрировали KEDA в предпочитаемый нами стек в Gimlet.

Вперед!

:::информация Первоначально опубликовано Юсефом Гуичи и Ласло Фогасом по адресу https://gimlet.io.

:::