.net core 3. Засетаплено: 3 пода основного приложения, 1 под парсер пдф, все это на 5 нодах(GKE). Поды не привязываются к нодам по каким либо лейбам, все рандомно раскидывается по нодам.
У нас есть проблема с постоянными рестартами контейнеров. В принципе давно известная проблема (https://blog.markvincze.com/troubleshooting-high-memory-usage-with-asp-net-core-on-kubernetes/). И мы знаем, что в нашем случае является причиной, сейчас работаем над этим.
Причина в том, что парсер во время парсинга съедает много памяти, лимиты стоят 900 mib на контейнеры приложения и парсера. Соответсвенно при достижении этого значения, одним контейнером либо суммой нескольких, срабатыват oomkiller.
Пока проблема утечки памяти фиксается на стороне кода, от девопс требуют оптимизировать кластер, сбалансировать. И тут я толком не знаю с чего начать, есть пару идей: 1. увеличить ресурсы; 2. применить podAntiAffinity, чтобы было по одному поду на ноде. Т к заметили что если
2 пода на одной ноде, то во время пика мемори рестартуют сразу 2(кстати не понятно это нормальное поведение куба???); 3. PodDisruptionBudget. Но с этой темой я еще не разобрался, может вообще это не относится к данному вопоросу.
Собственно хочу поинтересоваться, куда копать и что посоветуете?
Антиаффинити и реквесты лимиты нормальные. Рестартовать два пода поведение нормальное если пришел ООМ системный а не кубелета, так что вей - установить жесткие лимиты на рам
а это можно как-то проверить какой oom пришел системный или kubeleta?
в стаусах пода посмотри, он пишет причину рестарта (kubectl get po -o yaml po-name) там обычно так и пишет OOMKilled
спасибо. Еще есть два вопроса, 1. поды же могут перехать на другую свободную по ресурсам ноду если притык памяти на текущей или нет? 2. если oom может прибивать на текущей ноде 2 реплики приложения, может ли он каким-то образом задеть третью на другой ноде(сорян за глупый вопрос ) )?
1. если кто-то убьет под по какой-то причине, то вместо него новый под может запустится на той, более свободной, ноде. Но пока под жив - он будет жить
т е только в случае, например рестарта, но никак из-за превышения ресурсов, правильно?
Ну у тебя из-за нехватки ресурсов на ноде не запустится новый под. А который запустился ранее - будет работать, пока что-то не убьет его: oomkiller например, или он там сам помрет например
они переедут только в том случае если на текущей ноде не хватает свободной памяти в реквестах. (То есть доступная память на ноде минус сумма всех реквестов памяти подов на этой ноде) Такое может случиться, если например на такую ноду будет зашедулен pod с более выскоим приоритетом. Тогда твой под будет вытеснен из ноды. Банальное убийство пода по OOM не приведет к его переезду на другую ноду
нет. pod будет просто перезапущен на текущей ноде
Это смотря какая ситуация. Если он умрет, и запустится ему ресурсов уже не хватит - он запустится на другой ноде.
такого произойти не может. Так как: pod уже зашедулен на ноду, и его реквесты на ней учитваются. Перезапуск пода не ведет к его перешедуливанию, если он "упал" его реквесты все равно учитываются и в этот момент другой под не может "отобрать" его реквесты. За исключением случаев принудительного евикта например из-за приоритета/специальных taints/etc - но это может случиться в любой момент, поду для этого не обязательно перезапускаться(и причина перезапуска тоже не важна). Другими словами - pod по причине перезапуска никогда не уедет на другую ноду. Уехать он может, но по другим причинам, и эти причины не зависят от того, перезапускается этот pod или нет. (Можно конечно реализовать такой контроллер, который принудительно вытесняет pod из ноды или удаляет его, если тот убивается по OOM или перезапускается, но это не штатный функционал, по умолчанию такого поведения нет)
Обсуждают сегодня