Не получится, потому что в php-fpm всегда есть один воркер, который не PID 1. Т.е. всегда будет не-PID1, который может сдохнуть по OOM и никак не оповестить об этом.

У вас порядок перепутан :) сначала взять модный куб, потом раскатать абы как без вникания кубспреем, потом ковыряться и убить наглухо мастер (не забыв сказать что он умер будто сам), потом придти в чат с вопросами и вот только потом можно носить гордое звания девопса :) добро пожаловать, мы тут все такие

парси рсислог или журналд логи ООМ на нодах, выгрепывай хеши пода, контейнера из сообщения про ООМ и потом по АПИ куба узнавай какой это был под

А ещё лучше залить все логи в ёлку и искать в ней, хотя греп быстрее зачастую.

Нит, я напишу говнопатч в cAdvisor на новогодних праздниках.

Сделай, пожалуйста, так, чтобы он не грел воздух ? Жрет 20% ЦПУ - не меньше

И как часть kubelet?

Нит, я напишу говнопатч в cAdvisor на новогодних праздниках.

Вот недавно начал вкатываться в infrastructure as code и выделил для инфраструктуры отдельный гитовый репозиторий, где храню все ресурсы кластера. Но вот проблема в том, что у нас есть бекенд и несколько фронтендов. Каким образом лучше всего выкатывать обновления сервисов в кластер? Если в ci бекенда на каждый билд запускать деплой в репозитории кластера со свежей версией докер имейджа бекенда, то очевидно что может произойти так, что самая свежая версия фронта еще не готова к этим изменениям и на деплое завалится. Также рассматриваю вариант просто руками менять версии имейджей в репозитории кластера и пока эта идея мне кажется наилучшей, но все равно есть ощущение, что можно сделать лучше и автоматизированнее

> свежая версия фронта еще не готова к этим изменениям и на деплое завалится. Это забота разработчиков и на их отвественности. Тоже самое что и с миграциями, они не должны ломать текущий код.

Вот недавно начал вкатываться в infrastructure as code и выделил для инфраструктуры отдельный гитовый репозиторий, где храню все ресурсы кластера. Но вот проблема в том, что у нас есть бекенд и несколько фронтендов. Каким образом лучше всего выкатывать обновления сервисов в кластер? Если в ci бекенда на каждый билд запускать деплой в репозитории кластера со свежей версией докер имейджа бекенда, то очевидно что может произойти так, что самая свежая версия фронта еще не готова к этим изменениям и на деплое завалится. Также рассматриваю вариант просто руками менять версии имейджей в репозитории кластера и пока эта идея мне кажется наилучшей, но все равно есть ощущение, что можно сделать лучше и автоматизированнее

Посмотрите как сделано в истио - кратко говоря, разные версии бекендп роутят на соответствующие версии фронтенда - и все это хранится в отдельной репе, задается через CRD

как из пода получить IP/hostname соседних подов? или их DNS из куба

Бле, а я тут сижу на 1.10. А как они теперь метрики выгребают?

в том числе

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

а какие еще есть варианты, чтобы в чарт прокинуть эти IP/hostname?

Как хедлес их экспозишь, и получаешь dns-запись, которая ресолвится в ip контейнеров.

можно чуть больше подробностей?

а какие еще есть варианты, чтобы в чарт прокинуть эти IP/hostname?

Есть плагин для rabbitmq в k8s. Зайди в его репозиторий и там будут примеры, как правильно развернуть все

репа кролика или k8s?

спасибо, сейчас гляну

это я уже нашел

Ну вот эта статья отсылка к этому плагину. В статье даже все подробнее расписано, чем в репе

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

гуглится "rabbitmq kubernetes")) https://habr.com/company/true_engineering/blog/419817/

Не увидел тестов на отказоустойчивость

Я пробовал ронять кластер, в плоть до 1 экземпляра. Все работало

Не, это неинтересно.

А если Нетворк латенси большой? А если пакеты теряются? А если часы сбились ?

Т.е., повторюсь, интереснее кейсы "не выключили ноду" и посмотрели, что все ок. А прям нормальное исследование. Т.к. подгореть может в любой момент

Протестируйте, а потом нам отпишитесь о результатах, еще и ишью кинете на гитхаб разрабам плагина.

Ну, мне просто нравится подход. "Мы запустили хх в кубе в HA режиме". А где анализ граничных случаев? Почему, как пользователь, я должен этим заниматься. Т.е. ок - как ОПС - не вопрос, выберу адекватное решение под конкретную задачу и аргументируют выбор, но все остальное. Кхм. Детсад какой-то. Но обычно, конечно, полыхает по человеческому фактору...

не понял а причем тут пользователь

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

если ты не заметил, то кубер это не про "искаропки":D

Ну, мне просто нравится подход. "Мы запустили хх в кубе в HA режиме". А где анализ граничных случаев? Почему, как пользователь, я должен этим заниматься. Т.е. ок - как ОПС - не вопрос, выберу адекватное решение под конкретную задачу и аргументируют выбор, но все остальное. Кхм. Детсад какой-то. Но обычно, конечно, полыхает по человеческому фактору...

тут нет пользователя

А, если вы имеете в виду, что типа задолбали чуваки юзать кейсы, которые не поими как будут себя вести в критические моменты, то согласен о части. Я заюзал у себя это решение, предварительно почитав ишью на гитхабе и т.д. Что-то будет ломаться, буду решать и находить решения.