Лирика

cgroups

Еще 4 года назад использование контейнеров в production было экзотикой, но сейчас это уже норма как для маленьких компаний, так и для больших корпораций. Давайте попробуем посмотреть на всю эту историю с devops/контейнерами/микросервисами ретроспективно, взглянуть еще раз свежим взглядом на то, какие задачи мы изначально пытались решить, какие решения у нас есть сейчас и чего не хватает для полного счастья?

Я буду в большей степени рассуждать про production окружение, так как основную массу нерешенных проблем я вижу именно там.

Продолжаем серию статей про BPF — универсальную виртуальную машину ядра Linux — и в этом выпуске расскажем о том, какие типы программ BPF существуют, и как они используются в реальном мире капиталистического чистогана. Кроме этого, в конце статьи приведено некоторое количество ссылок, в частности, на две с половиной существующие книжки про BPF.

В ядре Linux версии 5.9 определено больше тридцати разных типов программ BPF, и про некоторые из этих типов я собираюсь написать по несколько статей, так что эта статья, поневоле, обзорная и не содержит такого количества технических деталей, как предыдущие. Но, тем не менее, мы постараемся, наконец-то, ответить на вопрос, зачем все это нужно и почему вокруг BPF так много шума.

Если вы хотите узнать, как именно BPF помогает эффективно решать задачи защиты от DDoS атак, распределения нагрузки на серверы, реализации сетевого стека kubernetes, защиты систем от нападения, эффективной трассировки систем 24x7 прямо в проде и многие другие, то добро пожаловать под кат.

Memory pressure -- это состояние, когда системе не хватает свободной памяти. Обычно его разделяют на moderate и critical. Moderate -- это когда памяти "мало, но пока еще жить можно", и дальнейшие выделения памяти могут вызвать проблемы с отзывчивостью из-за активной работы со swap-файлов или сбросов системных буферов и кэшей. Critical -- этап уже более серьезный, означающий "еще чуть-чуть, придет OOM-killer и начнет убивать процессы".

"Для чего нам это знать и контролировать?" -- на этот вопрос ответ будет в зависимости от того, что именно вы разрабатываете. Известный всем браузер Chromium (на котором основан Google Chrome), например, придерживается тактики "используем всю доступную память": если что-то можно забуферизовать и закэшировать в ОЗУ для ускорения работы, оно обязательно будет сделано. Зато при наступлении moderate memory pressure кэши и буферы очищаются, чтобы освободить пространство для работы других приложений, а при наступлении critical memory pressure браузер начинает выгружать фоновые вкладки, чтобы не допустить активации OOM-киллера.

Контрольные группы или cgroups — основные строительные блоки, обеспечивающие контейнеризацию на уровне операционной системы. Подобно процессам они организованы иерархически, и дочерние группы наследуют атрибуты родительских. В этой статье мы покажем, что наследование контрольных групп не всегда гарантирует последовательный и справедливый учёт ресурсов. Опишем стратегии, позволяющие избежать контроля использования ресурсов, и разберём основные причины, почему контрольные группы не могут отслеживать потребляемые ресурсы. Дополнительно исследуем сценарии, как вредоносные контейнеры могут потреблять больше ресурсов, чем разрешено. 

В предыдущей публикации мы рассмотрели, как организованы контрольные группы и почему их наследование не всегда гарантирует справедливый учёт ресурсов. Также успели проанализировать один из сценариев, при котором «вредоносные» контейнеры потребляют больше ресурсов, чем разрешено. В этой статье разберёмся с оставшимися сценариями и обсудим, как решать проблемы безопасности, возникающие из-за недостатков механизма cgroups.