Учитывая это сообщение об ошибке, вам необходимо установить ограничение памяти не менее 5 ГиБ. (И если вас это удивит, вы можете попытаться реплицировать свою рабочую нагрузку за пределы Kubernetes с помощью профилировщика кучи, чтобы увидеть, что происходит.)
В первой ситуации самому узлу не хватает памяти ( все эти 15 ГБ используются некоторым набором процессов). Здесь планировщик Kubernetes просматривает модули, работающие на узле, и находит те, которые значительно превышают запросы ресурсов. В сообщении об ошибке говорится, что вы используете на 5 ГиБ памяти больше, чем запрашивали, и ничего не запрашивали, поэтому вас выселяют. Модуль должен быть запланирован на другом узле.
Во второй ситуации вы ограничили объем памяти, который можно использовать, 2 или 3 ГиБ. Однако из первого сообщения об ошибке процесс хочет использовать 5 ГиБ. Когда вы достигнете этого настроенного предела, вы получите OOMKilled (нехватку памяти) и будете перезапущены.
Правильная установка этих ограничений - это немного искусство. Первое, что нужно знать, это сколько памяти фактически использует ваш процесс. Если вы можете запустить его в автономном режиме, базовые инструменты c, такие как top или ps, могут сказать вам это; Если у вас настроены метрики Kubernetes, инструмент мониторинга, такой как Prometheus, также может определять использование памяти для каждого модуля. Вам нужно установить предел памяти, по крайней мере, на самый большой объем памяти, который вы ожидаете от модуля (иначе он будет убит OOM).
Запросы памяти менее научны c. Если на узле 15 ГиБ ОЗУ, планировщик разрешит там работать подам с общим объемом запрошенной памяти 15 ГиБ. Если вы установите запросы ресурсов, близкие к лимитам ресурсов или равные им, тогда на узле сможет работать меньше других модулей; у узла меньше шансов исчерпать память; у отдельной капсулы меньше шансов быть выселенным; и если поды в совокупности не используют всю запрошенную память, то какой-то ресурс не будет использоваться. Установка более низкого запроса ресурсов позволяет большему количеству модулей работать на узле и более высокому использованию физических ресурсов (и, возможно, меньшему количеству узлов), но если это превышает 100%, вещи будут вытеснены.
Я обычно устанавливаю запросы ресурсов вокруг типичное использование процесса, из того же мониторинга, который вы использовали для определения предела. Я также видел очень разумные предложения по установке запросов и ограничений, чтобы избежать выселения подов. Это зависит от вашей терпимости к перезапуску подов по сравнению с вашей терпимостью к запуску (и оплате) дополнительных узлов с более низким коэффициентом использования.