Начальный всплеск ЦП JVM в контейнере Docker - PullRequest
0 голосов
/ 21 января 2019

У меня есть несколько Java-проектов, работающих в контейнерах Docker, управляемых с помощью Kubernetes.Я хочу включить горизонтальное автоматическое масштабирование (HPA) на основе ЦП, предоставленного Kubernetes, но мне трудно справиться с начальными скачками ЦП, вызванными JVM при инициализации контейнера.

В настоящее время я не установил ограничение ЦП в файлах yaml Kubernetes ни для одного из проектов, что в основном означает, что я позволяю модулям извлекать столько ЦП из среды, сколько они могут (я знаю, это плохая практика,но это позволяет мне загружать модули JVM менее чем за 30 секунд).
Проблема, которую это создает, заключается в том, что во время создания модуля в первые 3-4 минуты загрузка ЦП будет настолько высокой, что, если у меня будет установлено правило автомасштабирования, установите его.вызовет это.Автоматически масштабированный модуль будет раскручиваться и вызывать тот же всплеск и повторно запускать автоматическое масштабирование до тех пор, пока не будет достигнуто максимальное количество модулей и все не успокоится.
Я попытался установить ограничение ЦП в файле yaml kubernetes, но сумму, если процессор был моимпроекты не так уж и велики, поэтому, установив это значение не превышающим количество, мои стручки раскрутятся более чем за 5 минут, что недопустимо.
Я также мог бы увеличить задержку автоматического масштабирования до более чем 10 минут, но это глобальное правило, согласно которомутакже повлияет на развертывания, которые мне нужно масштабировать очень быстро, так что это также не подходит для меня.

Это пример конфигурации процессора и памяти для одного из моих модулей

 env:
        resources:
          requests:
            memory: "1300Mi"
            cpu: "250m"
          limits:
            memory: "1536Mi"

Я также недавно перешел на Java 10, который должен быть оптимизирован для контейнеров.Любой совет или комментарий будут высоко оценены.Заранее спасибо.

Редактировать:
Я также мог бы настроить hpa на основе пользовательских метрик prometheus, таких как http_requests, но эту опцию будет сложнее поддерживать, поскольку существует множество переменных, которые могут влиять на количество запросов.стручок может справиться.

1 Ответ

0 голосов
/ 21 января 2019

Зависит от вашей версии K8.

< 1.12:
В этой версии, как вы объясняете, у вас есть только флаг --horizontal-pod-autoscaler-upscale-delay для Kube-Controller или пользовательские метрики в HPAv2,https://v1 -11.docs.kubernetes.io / docs / tasks / run-application / horizontal-pod-autoscale /

=>1.12:
Здесь мы получилиновый алгоритм HPA, который отбрасывает unReady pod в своих вычислениях, что приводит к меньшему количеству автокоррекции.

https://github.com/kubernetes/kubernetes/pull/68068

Изменить санацию выборки ЦП в HPA.Игнорировать сэмплы, если:
- Стручок инициализируется - 5 минут от начала, заданного флагом
- стручок не готов
- стручок готов, но полное окно метрики не было выбрано с момента перехода
-Модуль инициализирован - через 5 минут после запуска, определяемого флагом:
- Модуль никогда не был готов после начального периода готовности.

Это должно вам помочь.

...