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

Тоесть патчить ядро?

Да, точно уверены..

Угу, все так. Не так давно сам с этим столкнулся и только так удалось решить.

Или юзать свежие ядра

Пичалька. =(

Коллеги, кто сталкивался и как решал проблему pleg is not healthy?
Периодически проскакивает на разных нодах. Запущенных контейнеров на них в районе 250, большого количества остановленных нет. В момент актуальности проблемы docker на команды отзывается, ps/info/curl сокета отвечают меньше секунды. Перезапуск docker и kubelet помогает на какое-то время.
Все возможные issues на гитхабе перечитал, единого мнения о причине проблемы там не нашел. В версиях старше 1.16 присутствует фикс таймаута при обращении к cni ( https://github.com/kubernetes/kubernetes/issues/45419#issuecomment-525669603 ), кроме этого никаких решений не увидел.

k8s v.1.15.3, flannel 0.11

Флант раздает вредные советы . SIGQUIT nginx будет гонка с лоад балансером. Надо просто sleep 60 делать и всё

Привет!
А можно раскрыть данный тезис?
Что значит гонка и про какой lb речь?

>Надо просто sleep 60 делать и всё
Но это же прям плохо, не?
Насколько растянется деплой с такой задержкой, если у вас 100 реплик или 200?

Всем привет! а кто-нибудь работал со https://spotinst.com/?

вот тут указан порядок что и как приосходит. если в preStop сделать SIGQUIT или любой другой graceful shutdown, то возникает гонка - лоадбалансеры и ингресы еще не перестали слать всякие запросы в под, но он уже перестал их принимать, от этого возникают разрывы , клиенты звонят и жалуются.

https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods

Как раз в статье мы и затронули эту проблему и расписали про использование sleep в lifecycle (только не 60 секунд, а только 1-2, чтобы не делать деплой слишком долгим) для ее решения

Мне кажется, что приложение должно корректно обрабатывать коды выхода, а не писать костыль на выброс пода

я про nginx. про fpm меня удивило:

command: ["/bin/sleep", "1", "kill -QUIT 1"]

такое работать не должно, разве что /bin/sleep какой-то хитрый, который принимает столько аргументов

Всем привет!

Кто нибудь подскажет, как сейчас наиболее популярная альтернатива Apache Benchmarking ab утилите?

Мне нужна какая то утилита, которую просто установить на Ubuntu 16, которая может слать N запросов в M параллельных потоков. Как это делала ab вот так ab -n N -c M http://example.org

ab не подходит, потому что она не поддерживает HTTP 1.1

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

Не ваша правда.
Приложение как раз нативно должно уметь обрабатывать graceful, если не умеет - приходится мудрить.

некорректно выразился, конечно. имейдж жс приложением должен корректно принимать коды и передавать их приложению