Spiky kubernetes HPA с метрическим числом сообщений unsacked pubsub

Question

В настоящее время у нас есть конвейер потоковой передачи данных: вызов API -> Google Pub / Sub -> BigQuery.Количество вызовов API будет зависеть от трафика на сайте.

Мы создаем развертывание kubernetes (в GKE) для загрузки данных из pub / sub в BigQuery.В этом развертывании есть горизонтальный модуль автоматического масштабирования (HPA) с metricName: pubsub.googleapis.com|subscription|num_undelivered_messages и targetValue: "5000".Эта структура способна автоматически масштабироваться при внезапном увеличении трафика.Тем не менее, это вызовет масштабируемость spiky.

То, что я имел в виду под spiky, выглядит следующим образом:

1. Количество непрочитанных сообщений увеличится больше целевого значения
2. Автоскалер увеличит количество стручков
3. Поскольку количество непакетированных будет медленно уменьшаться, но, поскольку оно все еще выше целевого значения, автоскалер будет увеличивать количество стручков -> это будет происходить, пока мы не нажмеммаксимальное количество стручков в автоскальсере
4. Количество неупакованных будет уменьшаться до тех пор, пока оно не опустится ниже целевого значения, и останется очень низким
5. Автоскалер уменьшит количество стручков до минимального количестваpods
6. Количество неупакованных сообщений снова увеличится, и будет идти аналогичная ситуация с (1), и оно войдет в цикл / цикл всплесков

Вот диаграмма, когда этостановится остроконечным (трафик растет, но он стабилен и не остроконечен): заостренный номер неподтвержденного сообщения в pub / sub

Мы установилиТревога в стекдрайвере, если количество неподтвержденных сообщений превышает 20 Кб, и в этом случае оно всегда будет вызываться часто.

Есть ли способ сделать HPA более стабильным (не колючим) в этом случае?

Любые комментарии, предложения или ответы приветствуются.

Спасибо!

Answer 1

Я имел дело с таким же поведением.В итоге я сгладил num_undelivered_messages с помощью скользящей средней.Я установил хрон c8s, который каждую минуту публикует среднее значение за последние 20 минут данных временного ряда в пользовательском показателе.Затем настроил HPA для ответа на пользовательский показатель.

Это сработало довольно хорошо, но не идеально.Я заметил, что как только среднее значение сходится к фактическому значению, HPA уменьшит сервис слишком низко.В итоге я просто добавил константу, поэтому пользовательская метрика просто средняя + константа.Для моего конкретного случая я нашел, что значение 25 000 сработало хорошо.

С этим, и после набора в targetAverageValue, автоматическое масштабирование было очень стабильным.

Я не уверен, если этоиз-за дефекта или просто характера метрики num_undelivered_messages при очень высоких нагрузках.

Редактировать: я использовал пакеты стека-драйвера / мониторинга golang.Существует простой способ агрегирования данных временных рядов;см. здесь в разделе «Агрегирование данных» https://cloud.google.com/monitoring/custom-metrics/reading-metrics

https://cloud.google.com/monitoring/custom-metrics/creating-metrics