вот ещё документацию читать, когда это было модно?😀

хорошо, вот положич вместое статического лимита впилили VPA такой базе, дальше что? будем такой dense packing делать чтобы потом из-за VPA скейлящего вврехи другие поды с этой ноды перезжали?

базы данных у меня в RDS вообще :)

Vpa с hpa работает, если использовать custom metrics, например rps

RT тогда уж

Что это?

response time

Ну это уже частности. Но я подумал и пока решил не трогать vpa

тогда уже надо перцентили делать

не по среднему же скейлить

И лимиты не ставлю

тогда уже надо перцентили делать

ну это уже от твоих хотелок зависит

И лимиты не ставлю

и реквесты тоже, надеюсь

Ставлю, иначе кластерный scaler работать не будет

какой-то дикий запад- лимиты не ставь, воруй-убивай

Оом сам разберётся

Лимитирование в контейнерах на моей памяти всегда работало через одного место. А гарантии полезны семи по себе

Согласен. Я делаю RAID1 на SSD + HDD. Планировщик сам разберётся с божьей помощью.

через одно место лимиты работали только в жабе емнип

Лимитирование в контейнерах на моей памяти всегда работало через одного место. А гарантии полезны семи по себе

на cpu вполне себе работает

Лимитирование в контейнерах на моей памяти всегда работало хорошо. И гарантии полезны сами по себе

через одно место лимиты работали только в жабе емнип

Она же heap не ограничивала автоматически просто. Но всякие параметры в JVM можно было всегда кидать и подстраивать под cgroup limit.

не стану гадать что там у человека не работало, особенно без ссылок на багрепорты

емнип там проблема была в том, что она систему целиком видела, а не то, что ей в лимитах нарисовано, поэтому весь автоматический расчет тредов гц и прочего происходил как будто она на ноде одна

JVM не в курсе про cgroups - поэтому спавнит потоки по количеству ядер

ну и память тоже

но это не только у явы а почти у всех

JVM не в курсе про cgroups - поэтому спавнит потоки по количеству ядер

уже в курсе

вроде бы есть тикет на маунт инфы из cgroups в /proc/cpuinfo как в lxc

уже в курсе

ей мишка рассказал

уже в курсе

уже это в 9 версии? а как быть легаси прогам?

stradat

по-моему даже в 8 завезли

бэкпортнули в восьмую

но не уверен

у монги аналогичная история с памятью - нужно в конфиге прописать нужные цифры

но вообще никто не мешает запускать восьмерку на одиннадцатой

а легаси могут юзать lxcfs

ну 8 это ж для кровавого ынтырпрайза все ещё недостижимая мечта

там хорошо если 6

а то ж и на 5 есть сидят

кровавому ынтырпрайзу бекпортнут хоть на солярку на синклерах, не стоит за них волноваться

компании Вадима или Ораклу денежки носят

на cpu вполне себе работает

Не все так просто. Например вот https://github.com/kubernetes/kubernetes/issues/51135

и что же вы ещё не бекпортнули на 6?

а то ж и на 5 есть сидят

все еще запускается на одиннадцатой

(а лучше бы нет, прибейте вы тайп эрежу уже наконец)

или просто это не афишируется?

В виртуозных контейнерах лимиты рекомендовали ставить с умом и только в крайних случаях

Не все так просто. Например вот https://github.com/kubernetes/kubernetes/issues/51135

Про CFS дырки в яве линкедин ещё в 2016 писали же и это же пофиксили в 1.10 или в 1.11 для целого числа ядер?

Это не специфично для Явы

поэтому наборот - ставьте cpu requests=limits(type int)

само собой, но т.к. ява генерирует потоки по числу ядер ноды а не cgroups она выжирает cfs циклы

и выходят дырки когда цпу не дается этому контейнеру

ну 8 это ж для кровавого ынтырпрайза все ещё недостижимая мечта

где кровавый ынтырпрайз с 5 джавой, а где кубернетисы

ну как где, бывает такие продукты продаются как коробочные решения

бывает что решил банк в облако мигрировать всякие некритические сервисы

или у них там есть отдел инноваций как в SAP

и есть SAP cloud

и есть SAP 😀 ну или ынтырпрайзы которые пошли в сап клауд

да много всего бывает

поэтому наборот - ставьте cpu requests=limits(type int)

Как раз таки не надо лимиты ставить, реквестов хватит. Ядро раздаст CPU shares пропорционально запросам, при этом приложение вылезешь за установленные рамки только если другим приложениям CPU не нужен. Таким образом повышается утилизация CPU. А лимиты тупо не дадут контейнеру CPU даже если он никому не нужен. Вот такая логика

Грубо говоря если есть два контейнера с запросом в 1 CPU, а на ноде доступно 4, то каждый получит по 2. С лимитом 2 ядра бы тупо простаивали

Как раз таки не надо лимиты ставить, реквестов хватит. Ядро раздаст CPU shares пропорционально запросам, при этом приложение вылезешь за установленные рамки только если другим приложениям CPU не нужен. Таким образом повышается утилизация CPU. А лимиты тупо не дадут контейнеру CPU даже если он никому не нужен. Вот такая логика

Те то что я делаю оверкомит вместо автоскейла не так плохо для лучшей утилизации

Грубо говоря если есть два контейнера с запросом в 1 CPU, а на ноде доступно 4, то каждый получит по 2. С лимитом 2 ядра бы тупо простаивали

с лимитом 2 на ноду приедет кто-нибудь другой

а если этим надо будет кпу больше 1, то его ресайзнет

с лимитом 2 на ноду приедет кто-нибудь другой

А с реквестом типа не приедет? Вы таки будет заморачиваться, чтоб у вас всегда сумма лимитов равнялась капасити? Смысл?

Н. Надёжность.

CPU share не менее надёжно, чем CPU quotes

Как раз таки не надо лимиты ставить, реквестов хватит. Ядро раздаст CPU shares пропорционально запросам, при этом приложение вылезешь за установленные рамки только если другим приложениям CPU не нужен. Таким образом повышается утилизация CPU. А лимиты тупо не дадут контейнеру CPU даже если он никому не нужен. Вот такая логика

ну враки же, простите https://kubernetes.io/blog/2018/07/24/feature-highlight-cpu-manager/ > When CPU manager is enabled with the “static” policy, it manages a shared pool of CPUs. Initially this shared pool contains all the CPUs in the compute node. When a container with integer CPU request in a Guaranteed pod is created by the Kubelet, CPUs for that container are removed from the shared pool and assigned exclusively for the lifetime of the container. Other containers are migrated off these exclusively allocated CPUs.

rtfm

И? Там нужно для этого лимит поставить?

т.е. ещё раз cpu requests=limits(type int) даёт результатом то что под прибит к конкретным ядрам

И? Там нужно для этого лимит поставить?

> in a Guaranteed pod

вроде черным по белому написано

в примере тоже вроде все понятно

CPU share не менее надёжно, чем CPU quotes

речь не про надёжность механизмов ядра

> in a Guaranteed pod

Там речь вообще по частный случай, м там как раз не используются лимиты, а выделяется ядро(а).

# Pod is in the Guaranteed QoS class because requests == limits requests: # CPU request is an integer cpu: 2 memory: "256M" limits: cpu: 2 memory: "256M"

...

даже продолжать полемику не хочется