Блог компании Southbridge
Системное администрирование
Серверное администрирование
DevOps
Комментарии 17
0
Интересно, когда пройдет мода в КДПВ класть фотку тонущего контейнеровоза в постах про Kubernetes.
0
Вывод 2: Задавайте ограничения по ресурсам

ИМХО, это должно быть правилом для любого использования контейнеров
0
Вообще очень не хватает возможность выставить квоту просто на неймспейс, мол вот вам 2 ядра 2 гига, разбирайтесь там.
0

Так они же вроде есть. Или на что те квоты, которые не "лимиты ресурсов" контейнеров?

0
Смотрите, если выставить квоту на неймспейс, но не выставить на контейнеры внутри они просто не запустятся.
Таким образом что бы выставить квоту на неймспейс, надо сначала в выставить квоты на контейнеры внутри (не на поды, именно на контейнеры внутри подов!), сложить всё это и выставить на неймспейс.
Решили добавить еще пару экземпляра пода в неймспейсе — они не стартанут, т.к. не хватит ресурсов, нужно повышать квоту на неймспейс в целом.
Ну или overprovisioning дикий устраивать.
Я же мечтаю о «в неймспейсе что-то происходит, на все контейнеры даю 2 гб памяти, пущай сами делят».
Условно, как виртуальная машина позволяет выделить строго определённое число ресурсов под все процессы внутри себя, без строго разделения по процесса. Ресурсы просто общие, но ограниченные.
0

Ха, динамическое распределение ресурсов квоты по контейнерам внутри namespace? Звучит настолько логично, что трудно поверить в отсутствие такой возможности.

0
Я так понимаю, суть в том, что квоты задаются через cgroups при старте процесса (контейнера) и они не динамические в принципе. Плюс всё это размазано по нескольким нодам, что усложняет задачу.

Мне бы хватило просто лимитов вида «ни один из контейнеров в этом неймспейсе не может отожрать больше 2000 мб памяти», это уже уровень логики кубера, но он так не умеет.
0
Мне кажется, это слишком «грубо», т.е. малополезно. Может, я просто еще не научился использовать неймспейсы.
0
Банальный пример: мы хотим что бы разработчик в своём dev неймспейсе шальными экспериментами не выжрал всю память ноды.
Сейчас, если мы ставим квоту на этот неймспейс, то разработчик обязан в каждом своём контейнере прописывать явно лимиты, причем сумма лимитов не может быть больше отведённого на неймспейс.
0
Вывод 2: Задавайте ограничения по ресурсам

Но ведь тогда эти поды будут убиваться в последнюю очередь (при нехватке ресурсов из-за падения ноды).
А поды без ограничений будут убиты первыми.
Или уже что-то поменялось в кубере?
0
Подам без ограничения можно выставить request равный limit например, тем самым можно регулировать порядок смерти подов по OOM.
0

Подов без ограничений не должно быть. Kubernetes не следовало допускать возможность запуска таких.

+2
Для тех, кому интересно, что могло быть причиной повышенной дисковой активности: сама по себе нехватка памяти. При увеличении memory pressure сначала начинают сбрасываться дисковые кэши, I/O растёт как из-за сброса грязных страниц, так и из-за уменьшения размеров кэшей, а когда и этой меры оказывается недостаточно, ядро начинает выгружать страницы, занятые отображенными в память файлами программ. Когда программе передаётся управление и поток исполнения доходит до такой страницы, он снова начинает читать её с диска, и т.д.
В общем, при острой нехватке памяти ядро (ну, по крайней мере Linux) пытается сделать всё, чтобы выжить, хотя на самом деле непонятно, действительно ли это так необходимо, поскольку, с одной стороны, процессу с утечкой в любом случае уже ничем не помочь (если есть утечка, память однажды всё равно закончится), а с другой стороны, подобные попытки сохранить жизнь утекающему процессу и отложить вызов OOM-Killer иногда приводят к такому замедлению системы, что проше сразу всю машину ребутнуть, потому что она десятки минут обрабатывает даже ввод с клавиатуры. Вспомним известный баг 12309, говорят, его аналог и в недавних версиях ядра ещё стреляет.
0

О, да, хотел написать то же самое, но Вы меня опередили.
+1
На самом деле получается, что отключение свопа помогает, но не до конца — все равно тюнить vm.
Кстати, как относитесь к отключению overcommit памяти в линуксе?

0
В целом никак не отношусь, по-моему в каждом конкретном случае надо смотреть, насколько оно помогает или наоборот вредит. Если утечек памяти нет и её потребление в целом стабильно, не вижу в overcommit ничего плохого.
А вообще я не то чтобы большой специалист по настройке всех этих параметров, просто рассказал то, что знаю, так как кому-то может помочь и сэкономить часть времени на поиск несуществующих проблем в своем приложении. Что, кстати, усугубляется невозможностью простыми средствами наподобие iotop узнать топ процессов по IO на конкретное блочное устройство.
0

Если заменить fluentd на fluentbit можно было бы исключить побочные явления от Ruby.
А fluentd метрики отдаёт (fluentbit умеет)? Перед самым OOM интересно бы метрики самого fluentd посмотреть.

Только полноправные пользователи могут оставлять комментарии., пожалуйста.