DevSecOps Talks

Автоматическое масштабирование с помощью KEDA с использованием пользовательских метрик RED

Всем привет! 👋

Статья рассказывает, как настроить автоскейлинг в Kubernetes с помощью Kubernetes Event-driven Autoscaling (KEDA) и Rate, Errors, Duration (RED) метрик из Prometheus.

Автор начинает с задачи: старые сервисы перегружались в часы пик, но простаивали в остальное время. Отмечается, что традиционные метрики CPU/памяти не всегда отражают реальную нагрузку на приложение, поэтому для масштабирования был выбран подход, ориентированный на пользовательский опыт.

Ключевые шаги:
🎯 Архитектура решения: K8s + KEDA + Prometheus. Рассматривается сравнение KEDA с другими средствами (HPA, Cluster Autoscaler, Knative, самописные решения). KEDA поддерживает множество источников метрик (включая Prometheus и пользовательские), умеет масштабироваться «до нуля» и гибко настраивается через ScaledObject.
🎯 Тестирование нагрузки (Locust, JMeter) для имитации пиковых нагрузок, настройка мониторинга через Grafana.
🎯 Основные проблемы и их решения: оптимизация PromQL-запросов (подбор метрик, окон агрегации, упрощение запросов). Также нужно было сбалансировать быстродействие и устойчивость: регулировать pollingInterval и cooldownPeriod, а при уменьшении нагрузки — устанавливать разные пороги для масштабирования вверх и вниз. Кроме того, при масштабировании стали заметны узкие места внешних систем (например, БД). Для этого внедрили пул соединений, реплики для чтения базы данных и кэширование, чтобы помочь интеграционным компонентам выдерживать увеличенную нагрузку.
🎯 Результаты: улучшение отклика сервисов, оптимизированы расходы на облако, более надёжная архитектура и аналитика.

И самое полезное — в статье есть конкретные примеры манифестов и команд, которые можно повторить у себя! 🚀

Medium

Auto-scaling with KEDA Using Custom RED Metrics from Prometheus

Introduction

🔥8👍5❤3🥰1

www.tgoop.com/devsecops_weekly/1295

2.62K viewsAug 22 at 04:25

Автоматическое масштабирование с помощью KEDA с использованием пользовательских метрик RED

Всем привет! 👋

Статья рассказывает, как настроить автоскейлинг в Kubernetes с помощью Kubernetes Event-driven Autoscaling (KEDA) и Rate, Errors, Duration (RED) метрик из Prometheus.

Автор начинает с задачи: старые сервисы перегружались в часы пик, но простаивали в остальное время. Отмечается, что традиционные метрики CPU/памяти не всегда отражают реальную нагрузку на приложение, поэтому для масштабирования был выбран подход, ориентированный на пользовательский опыт.

Ключевые шаги:
🎯 Архитектура решения: K8s + KEDA + Prometheus. Рассматривается сравнение KEDA с другими средствами (HPA, Cluster Autoscaler, Knative, самописные решения). KEDA поддерживает множество источников метрик (включая Prometheus и пользовательские), умеет масштабироваться «до нуля» и гибко настраивается через ScaledObject.
🎯 Тестирование нагрузки (Locust, JMeter) для имитации пиковых нагрузок, настройка мониторинга через Grafana.
🎯 Основные проблемы и их решения: оптимизация PromQL-запросов (подбор метрик, окон агрегации, упрощение запросов). Также нужно было сбалансировать быстродействие и устойчивость: регулировать pollingInterval и cooldownPeriod, а при уменьшении нагрузки — устанавливать разные пороги для масштабирования вверх и вниз. Кроме того, при масштабировании стали заметны узкие места внешних систем (например, БД). Для этого внедрили пул соединений, реплики для чтения базы данных и кэширование, чтобы помочь интеграционным компонентам выдерживать увеличенную нагрузку.
🎯 Результаты: улучшение отклика сервисов, оптимизированы расходы на облако, более надёжная архитектура и аналитика.

И самое полезное — в статье есть конкретные примеры манифестов и команд, которые можно повторить у себя! 🚀

BY DevSecOps Talks