Калькулятор реплик HPA в Kubernetes

Введите, сколько подов работает сейчас, текущее значение метрики (например, среднюю загрузку CPU в процентах) и цель из вашего HorizontalPodAutoscaler. Калькулятор применит правило масштабирования HPA и покажет, к какому числу реплик он будет стремиться, добавит ли поды, уберёт или оставит как есть и упёрся ли в предел.

Работает в браузере: всё, что вы вводите, никуда не отправляется.

Инструмент помог?

Как пользоваться

Введите текущее число реплик и текущее значение метрики — в тех же единицах, что и цель (проценты для загрузки CPU, запросы в секунду для своей метрики и т. д.).
Введите цель из спецификации HPA, а также minReplicas и maxReplicas.
Оставьте допуск 10 %, если в кластере не задан другой horizontal-pod-autoscaler-tolerance.

Формула

отношение = текущая метрика ÷ цель
Если |отношение − 1| ≤ допуск: нужно = текущее (масштабирования нет)
Иначе: нужно = ceil(текущие реплики × отношение)
Затем результат ограничивается диапазоном minReplicas … maxReplicas

Пример

Deployment работает на 4 подах со средней загрузкой CPU 90 %, цель — 60 %, пределы 2…10:

отношение: 90 ÷ 60 = 1,5 — вне полосы 10 %;
без округления: 4 × 1,5 = 6; нужно реплик — 6;
решение — Увеличить; предел — Нет.

Советы

Оставляйте запас в maxReplicas. Если калькулятор часто показывает «Ограничено maxReplicas», поды остаются перегруженными — поднимите предел или ёмкость узлов.
Чем ниже цель, тем раньше масштабирование. Цель 50 % по CPU оставляет запас на всплески, пока стартуют новые поды; 80 % экономнее, но реагирует позже.
Сначала проверьте requests. Если запросы CPU далеки от реального потребления, проценты загрузки вводят автомасштабирование в заблуждение.

Частые вопросы

Как HPA считает нужное число реплик?

desiredReplicas = ceil(currentReplicas × currentMetricValue ÷ desiredMetricValue). Для 4 подов при загрузке CPU 90 % и цели 60 %: 4 × 90 ÷ 60 = 6 подов. Затем результат ограничивается значениями minReplicas и maxReplicas.

Почему HPA не масштабирует, когда метрика чуть выше цели?

Контроллер ничего не делает, пока отношение метрика ÷ цель отличается от 1,0 не больше чем на допуск — по умолчанию 0,1 (10 %). 8 подов при 64 % и цели 60 % дают отношение 1,067, поэтому число подов не меняется, хотя ceil(8,53) было бы 9.

Загрузка CPU считается от limits или от requests?

От requests. Цель Utilization 60 % означает 60 % от запрошенного каждым подом CPU в среднем по подам. Поды без запроса CPU нельзя масштабировать по загрузке CPU.

Что калькулятор не учитывает?

Здесь только основная формула. Настоящий контроллер ещё использует окно стабилизации при уменьшении (по умолчанию 5 минут), политики, ограничивающие скорость добавления и удаления подов, отдельно обрабатывает неготовые поды и поды без метрик, а при нескольких метриках берёт наибольший результат.

Ещё в разделе «Разработчикам»

Все инструменты раздела: Разработчикам ·Обновлено 7 ноября 2026 г.