читал что там может быть массив и какой из них клиентский тогда будет?

Если есть такой вопрос, значит не дочитал

Мда, точно уже не буду пробовать, я тогда уж лучше js буду генерить конфиги, чем jsonnet. import { set } from 'unchanged' const limits = { ... }; export default set('containers[0].resources.limits', limits, defaultConfig);

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

Если у вас массив уже есть в какой то local переменной arr, то можно arr2 = [arr[0] + 100] + arr[1:];

Мда, точно уже не буду пробовать, я тогда уж лучше js буду генерить конфиги, чем jsonnet. import { set } from 'unchanged' const limits = { ... }; export default set('containers[0].resources.limits', limits, defaultConfig);

update-in из clojure 🙈 имутабельность не должна быть болью для разработчика

Эта опция на горизонте, но пока не разбирался подробно, поэтому боюсь соврать.

Збс тема

если в неймспейсе где опероатор, то зачем у оператора права на чтение сервисмониторов в других неймспейсах

https://www.forbes.com/sites/justinwarren/2018/12/19/service-mesh-is-super-hot-why/ статья в форбсе - ребята к успеху пришли

Потому что так код устроен. Если хочется чтобы оно создавало Прометей в одном неймспейсе, но следило за сервис мониторами в других , то там есть WIP ПР от меня . WIP потому что все их тесты не переписал на мультинеймспейность

А как же поле ServiceMonitorNamespaceSelector в PrometheusSpec?

Потому что так код устроен. Если хочется чтобы оно создавало Прометей в одном неймспейсе, но следило за сервис мониторами в других , то там есть WIP ПР от меня . WIP потому что все их тесты не переписал на мультинеймспейность

Поэтому я и интересовался опцией --experimental-memcg-notification или вроде того

у меня уже заработало

Это не особо много бонусов принесёт. Тут просто разница, как в ядре между polling и interrupts. Interrupt в данном случае - это memcg notification. Т.е. о проблеме в kubelet прилетит "Interrupt" (на самом деле message в eventfd(2)). Это даст несколько секунд. Принесут ли они пользы? Не знаю. Учитываю, что фичу с memcg notification пилят уже третий год - вряд ли.

А почему нет? Ведь за эти несколько секунд какой-нибудь контейнер вполне может выжрать всю память

Да, но... но в общем-то да. Было бы полезно.

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

Насколько я в принципе понимаю, задание реквестов и лимитов по ресурсам ничего для подов не резервирует и в критических ситуациях все одно упирается в своевременность выселения подов согласно QoS

очень даже резервирует, а если делать requests=limits то поды ровно на ноды ложатся и выселяться ничего не будет

Конечно, но не всегда же можно у всех так ставить QoS в guaranteed

Конечно, но не всегда же можно у всех так ставить QoS в guaranteed

конечно если мы хостинг какой и реселлим цпу и память то надо оверкоммит делать но если мы в своем кластере свои ворклоады гоняем - я пока не знаю кейса зачем делать requests != limits

более того, с 1.11 или какой там версии где цпу шедулер подрихтовали ещё и цпу очень желательно округлять до целого числа чтобы под прибивался на конкретные ядра и не было контекст свитчей

Ну и да, тот же HPA использовать для скейлинга, тогда guaranteed тоже не всегда полезен. Особенно на baremetal.

почему? HPA настроить правильно

или мы хотим 100% цпу загрузить (и пол на 95% перцентили по латенси и т.д.)?

Да, я не туда в рассуждениях заехал. Но я про I/O heavy workload'ы (коих большинство) всё же вещаю.

Ну и да, тот же HPA использовать для скейлинга, тогда guaranteed тоже не всегда полезен. Особенно на baremetal.

ну ставим там цпу requests/limit поменьше

С memory не так чисто всё, как я вижу. Хотя... зависит от программы, наверное. Я был на HL++ 2018 на презентации чувака, который топил за guaranteed QoS. В общем-то, проникся.

короче уметь готовить надо, чтобы везде сделать guaranteed и при этом чтобы не было много простаивающих ресурсов

с memory плохо конечно, например с тем же php-fpm памятьв все время скачет туда-сюда но как бы я опять не вижу зачем ставить requests меньше limits огребать лишний раз OOM kill - в php-fpm ты их и так наотгребаешься будь здоров (прямо вижу будущее Andor)

Да. Причём node level OOM, а не in-cgroup OOM, что может убить что-то из другой cgroup или что-то не в cgroup kubepods вообщем. Например, journald.

с memory плохо конечно, например с тем же php-fpm памятьв все время скачет туда-сюда но как бы я опять не вижу зачем ставить requests меньше limits огребать лишний раз OOM kill - в php-fpm ты их и так наотгребаешься будь здоров (прямо вижу будущее Andor)

как не было простаивающих? тебе все равно нужно место на нодах чтобы делать rolling update

о да, помню эпичную багу с убиванием journald на coreos 2 года назад

можно пример когда нельзя?

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