Kubernetes HPA - Как избежать увеличения загрузки ЦП
HPA - Как избежать увеличения масштабирования при скачке загрузки ЦП (не при запуске). Когда бизнес-конфигурация загружается для другой страны, загрузка ЦП увеличивается на 1 минуту, но мы хотим избежать увеличения на эту 1 минуту.
ниже рис. CurrentMetricValue - это просто текущее значение из матрицы или среднее значение от последнего опроса до текущей продолжительности опроса --horizontal.-pod-autoscaler-sync-period
1 ответ
Интервал проверки HPA по умолчанию составляет 30 секунд. Это можно настроить с помощью, как вы упомянули, изменив значение флага--horizontal-pod-autoscaler-sync-period
диспетчера контроллера.
Автоматическое масштабирование горизонтальных модулей реализовано в виде контура управления, период которого контролируется флагом диспетчера контроллеров --horizontal-pod-autoscaler-sync-period.
В течение каждого периода диспетчер контроллера запрашивает использование ресурсов по метрикам, указанным в каждом определении HorizontalPodAutoscaler. Диспетчер контроллера получает метрики либо из API метрик ресурсов (для метрик ресурсов для каждого модуля), либо из API пользовательских метрик (для всех других метрик).
Чтобы изменить / добавить флаги в kube-controller-manager - у вас должен быть доступ к вашему /etc/kubernetes/manifests/
каталог на главном узле и иметь возможность изменять параметры в /etc/kubernetes/manifests/kube-controller-manager.yam
л.
Примечание: вы не можете сделать это в GKE, EKS и других управляемых кластерах.
Что еще рекомендую увеличить --horizontal-pod-autoscaler-downscale-stabilization
(замена для --horizontal-pod-autoscaler-upscale-delay
).
Если вас беспокоят длительные перерывы в работе, я бы порекомендовал настроить индивидуальную метрику (1, если сеть не работала последней ${duration}
, 0 в противном случае) и установка целевого значения метрики на 1 (в дополнение к автомасштабированию на основе ЦП). Сюда:
Если сеть не работала в прошлом ${duration}
Рекомендация на основе настраиваемой метрики будет равна текущему размеру вашего развертывания. Максимальное количество этой рекомендации и очень низкая рекомендация ЦП будут равны текущему размеру развертывания. Уменьшения масштаба не будет, пока подключение не будет восстановлено (+ несколько минут после этого из-за окна стабилизации уменьшения масштаба).
Если сеть доступна, рекомендация, основанная на метрике, будет равна 0. Максимально с рекомендацией ЦП она будет равна рекомендации ЦП, и автомасштабирование будет работать нормально. Я думаю, что это решает вашу проблему лучше, чем ограничение размера шага автомасштабирования. Ограничение размера шага автомасштабирования только замедлит скорость, с которой уменьшается количество модулей, поэтому более длительное отключение сети все равно приведет к сокращению развертывания до минимально допустимого размера.
Вы также можете использовать масштабирование на основе памяти
Поскольку в Kubernetes невозможно создать hpa на основе памяти, был написан сценарий для достижения того же. Вы можете найти наш скрипт здесь, перейдя по этой ссылке:
https://github.com/powerupcloud/kubernetes-1/blob/master/memory-based-autoscaling.sh
Клонируйте репозиторий:
https://github.com/powerupcloud/kubernetes-1.git
а затем перейдите в каталог Kubernetes. Выполните команду помощи, чтобы получить инструкции:
./memory-based-autoscaling.sh --help
Подробнее здесь: автомасштабирование на основе памяти.