Комментарии 18
Интересно, когда пройдет мода в КДПВ класть фотку тонущего контейнеровоза в постах про Kubernetes.
Вывод 2: Задавайте ограничения по ресурсам
ИМХО, это должно быть правилом для любого использования контейнеров
Вообще очень не хватает возможность выставить квоту просто на неймспейс, мол вот вам 2 ядра 2 гига, разбирайтесь там.
Так они же вроде есть. Или на что те квоты, которые не "лимиты ресурсов" контейнеров?
Смотрите, если выставить квоту на неймспейс, но не выставить на контейнеры внутри они просто не запустятся.
Таким образом что бы выставить квоту на неймспейс, надо сначала в выставить квоты на контейнеры внутри (не на поды, именно на контейнеры внутри подов!), сложить всё это и выставить на неймспейс.
Решили добавить еще пару экземпляра пода в неймспейсе — они не стартанут, т.к. не хватит ресурсов, нужно повышать квоту на неймспейс в целом.
Ну или overprovisioning дикий устраивать.
Я же мечтаю о «в неймспейсе что-то происходит, на все контейнеры даю 2 гб памяти, пущай сами делят».
Условно, как виртуальная машина позволяет выделить строго определённое число ресурсов под все процессы внутри себя, без строго разделения по процесса. Ресурсы просто общие, но ограниченные.
Таким образом что бы выставить квоту на неймспейс, надо сначала в выставить квоты на контейнеры внутри (не на поды, именно на контейнеры внутри подов!), сложить всё это и выставить на неймспейс.
Решили добавить еще пару экземпляра пода в неймспейсе — они не стартанут, т.к. не хватит ресурсов, нужно повышать квоту на неймспейс в целом.
Ну или overprovisioning дикий устраивать.
Я же мечтаю о «в неймспейсе что-то происходит, на все контейнеры даю 2 гб памяти, пущай сами делят».
Условно, как виртуальная машина позволяет выделить строго определённое число ресурсов под все процессы внутри себя, без строго разделения по процесса. Ресурсы просто общие, но ограниченные.
Ха, динамическое распределение ресурсов квоты по контейнерам внутри namespace? Звучит настолько логично, что трудно поверить в отсутствие такой возможности.
Я так понимаю, суть в том, что квоты задаются через cgroups при старте процесса (контейнера) и они не динамические в принципе. Плюс всё это размазано по нескольким нодам, что усложняет задачу.
Мне бы хватило просто лимитов вида «ни один из контейнеров в этом неймспейсе не может отожрать больше 2000 мб памяти», это уже уровень логики кубера, но он так не умеет.
Мне бы хватило просто лимитов вида «ни один из контейнеров в этом неймспейсе не может отожрать больше 2000 мб памяти», это уже уровень логики кубера, но он так не умеет.
Мне кажется, это слишком «грубо», т.е. малополезно. Может, я просто еще не научился использовать неймспейсы.
Банальный пример: мы хотим что бы разработчик в своём dev неймспейсе шальными экспериментами не выжрал всю память ноды.
Сейчас, если мы ставим квоту на этот неймспейс, то разработчик обязан в каждом своём контейнере прописывать явно лимиты, причем сумма лимитов не может быть больше отведённого на неймспейс.
Сейчас, если мы ставим квоту на этот неймспейс, то разработчик обязан в каждом своём контейнере прописывать явно лимиты, причем сумма лимитов не может быть больше отведённого на неймспейс.
Вывод 2: Задавайте ограничения по ресурсам
Но ведь тогда эти поды будут убиваться в последнюю очередь (при нехватке ресурсов из-за падения ноды).
А поды без ограничений будут убиты первыми.
Или уже что-то поменялось в кубере?
Для тех, кому интересно, что могло быть причиной повышенной дисковой активности: сама по себе нехватка памяти. При увеличении memory pressure сначала начинают сбрасываться дисковые кэши, I/O растёт как из-за сброса грязных страниц, так и из-за уменьшения размеров кэшей, а когда и этой меры оказывается недостаточно, ядро начинает выгружать страницы, занятые отображенными в память файлами программ. Когда программе передаётся управление и поток исполнения доходит до такой страницы, он снова начинает читать её с диска, и т.д.
В общем, при острой нехватке памяти ядро (ну, по крайней мере Linux) пытается сделать всё, чтобы выжить, хотя на самом деле непонятно, действительно ли это так необходимо, поскольку, с одной стороны, процессу с утечкой в любом случае уже ничем не помочь (если есть утечка, память однажды всё равно закончится), а с другой стороны, подобные попытки сохранить жизнь утекающему процессу и отложить вызов OOM-Killer иногда приводят к такому замедлению системы, что проше сразу всю машину ребутнуть, потому что она десятки минут обрабатывает даже ввод с клавиатуры. Вспомним известный баг 12309, говорят, его аналог и в недавних версиях ядра ещё стреляет.
В общем, при острой нехватке памяти ядро (ну, по крайней мере Linux) пытается сделать всё, чтобы выжить, хотя на самом деле непонятно, действительно ли это так необходимо, поскольку, с одной стороны, процессу с утечкой в любом случае уже ничем не помочь (если есть утечка, память однажды всё равно закончится), а с другой стороны, подобные попытки сохранить жизнь утекающему процессу и отложить вызов OOM-Killer иногда приводят к такому замедлению системы, что проше сразу всю машину ребутнуть, потому что она десятки минут обрабатывает даже ввод с клавиатуры. Вспомним известный баг 12309, говорят, его аналог и в недавних версиях ядра ещё стреляет.
О, да, хотел написать то же самое, но Вы меня опередили.
+1
На самом деле получается, что отключение свопа помогает, но не до конца — все равно тюнить vm.
Кстати, как относитесь к отключению overcommit памяти в линуксе?
В целом никак не отношусь, по-моему в каждом конкретном случае надо смотреть, насколько оно помогает или наоборот вредит. Если утечек памяти нет и её потребление в целом стабильно, не вижу в overcommit ничего плохого.
А вообще я не то чтобы большой специалист по настройке всех этих параметров, просто рассказал то, что знаю, так как кому-то может помочь и сэкономить часть времени на поиск несуществующих проблем в своем приложении. Что, кстати, усугубляется невозможностью простыми средствами наподобие iotop узнать топ процессов по IO на конкретное блочное устройство.
А вообще я не то чтобы большой специалист по настройке всех этих параметров, просто рассказал то, что знаю, так как кому-то может помочь и сэкономить часть времени на поиск несуществующих проблем в своем приложении. Что, кстати, усугубляется невозможностью простыми средствами наподобие iotop узнать топ процессов по IO на конкретное блочное устройство.
Поэтому умные товарищи для управляющего софта делают mlockall() но почему-то в линуксах это не принято. Плюс есть щас какойто демон который киляет до оом.
Если заменить fluentd на fluentbit можно было бы исключить побочные явления от Ruby.
А fluentd метрики отдаёт (fluentbit умеет)? Перед самым OOM интересно бы метрики самого fluentd посмотреть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разбор: ООМ на узле Kubernetes