Commands
KEDA

kubectl get scaledobjects: Просмотр ScaledObject: статус, триггеры, текущий scaler

Просмотр ScaledObject: статус, триггеры, текущий scaler

#command#keda#kubectl

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

Базовый синтаксис

Самая простая команда выводит список всех ScaledObject в текущем namespace.

kubectl get scaledobjects

Что ты увидишь:

  • NAME: Имя самого ScaledObject.
  • SCALERS: Количество активных скалеров (триггеров). Если 0, масштабирование не работает.
  • SCALEDOBJECT: Имя целевого ресурса (например, Deployment или StatefulSet), которым управляет KEDA.
  • READY: Состояние готовности (True/False). False — есть проблемы с конфигурацией триггера.
  • ACTIVE: Активен ли скалер (True/False). False означает, что триггер не активирован (например, длина очереди равна 0).
  • PAUSED: Находится ли масштабирование на паузе.

Полезные флаги

-n — проверка в другом namespace

Когда поды не масштабируются, первым делом смотрю, есть ли там вообще ScaledObject. Часто проблема в том, что его забыли создать в нужном namespace.

kubectl get scaledobjects -n data-processing

-o yaml — детальная диагностика проблемы

Если в колонке READY или ACTIVE стоит False, этой командой получаю полную конфигурацию. В выводе ищу секции status.conditions и spec.triggers.

kubectl get scaledobject my-queue-scaler -o yaml

В YAML смотрю на два ключевых места: status.conditions с сообщением об ошибке и spec.triggers, чтобы проверить корректность параметров (например, имя очереди или подключения).

Типичные сценарии

1. Поиск «мёртвых» ScaledObject Ищу объекты, у которых триггеры не активны (ACTIVE = False), хотя нагрузка должна быть. Это может указывать на проблемы с источником метрик (например, недоступность очереди RabbitMQ) или неверные пороговые значения.

kubectl get scaledobjects -A | grep False

2. Проверка состояния скалеров перед деплоем После обновления конфигурации ScaledObject через kubectl apply сразу смотрю его статус в широком формате, чтобы убедиться, что он перешёл в состояние Ready.

kubectl get scaledobject my-app -o wide

Частые ошибки

Ошибка: No resources found Самая частая. Пользователь забывает указать namespace (-n), если контекст kubectl настроен на другое пространство, или ScaledObject действительно не создан. Всегда сначала проверяю правильность namespace.

Ошибка: Игнорирование колонки READY Если READY = False, масштабирование не будет работать, даже если ACTIVE = True. Нужно сразу смотреть детали через kubectl get scaledobject <name> -o yaml и искать причину в status.conditions. Частые причины — ошибки в ссылке на Secret для подключения или неверный тип триггера.