Если вы админите хосты под Docker/containerd или держите Kubernetes‑кластер, cgroup — это не теория «про ядро», а ежедневная практика: лимиты CPU/памяти «срабатывают странно», I/O ограничивается не так, как ожидали, метрики в мониторинге меняют смысл, а обновление дистрибутива внезапно ломает привычные пути в /sys/fs/cgroup.
В 2026 году большинство актуальных дистрибутивов по умолчанию ориентированы на cgroup v2 и режим systemd unified hierarchy. Но cgroup v1 по-прежнему встречается на старых ядрах/образах, в некоторых корпоративных сборках и там, где обновление агентов наблюдаемости сделано «не до конца». Ниже — практическое сравнение cgroup v1 vs cgroup v2 с фокусом на Docker, Kubernetes и метрики.
Короткий контекст: что такое cgroup и при чём тут systemd
cgroup (control groups) — механизм ядра Linux для ограничения и учёта ресурсов по группам процессов. В контейнерном мире «группой» обычно становится контейнер, под, сервис или конкретный workload.
systemd давно стал главным менеджером процессов на хосте и активно использует cgroup для изоляции/лимитов сервисов. Отсюда и термин unified hierarchy — режим, когда systemd управляет единой иерархией cgroup v2 (вместо набора разрозненных деревьев v1).
Практический вывод: на современных хостах именно systemd часто определяет, как будет выглядеть дерево cgroup, и как контейнерный runtime должен туда «вписаться».
cgroup v1 vs cgroup v2: ключевые отличия без лишней теории
1) Иерархия: «много деревьев» против «одного дерева»
cgroup v1 — это набор независимых иерархий по контроллерам. Исторически получалось так, что cpu, memory, blkio монтировались отдельно, и один процесс мог одновременно принадлежать разным cgroup в разных деревьях. Это давало гибкость, но и добавляло неоднозначностей.
cgroup v2 — это единая иерархия: процесс находится в одном месте дерева, а контроллеры включаются/выключаются по веткам. Модель проще, а поведение обычно более предсказуемое.
2) Контроллеры CPU/Memory/IO: что меняется в интерфейсах
Разница заметнее всего в «контейнерных» контроллерах:
- CPU: в v1 часто встречаются
cpu.shares,cpu.cfs_quota_us,cpu.cfs_period_us. В v2 — более единый интерфейс:cpu.max(квота/период),cpu.weight(вес). - Memory: в v2 интерфейс прямее и богаче для эксплуатации:
memory.max(жёсткий потолок),memory.high(мягкий лимит для давления/reclaim),memory.current(текущее потребление), события OOM — в более консистентном виде. - IO: вместо v1‑контроллера
blkio— v2‑контроллерio, который лучше соответствует современному блочному стеку и чаще даёт ожидаемые результаты (при условии, что storage‑цепочка это поддерживает).
Важно: «лучше» не означает «всегда быстрее». Обычно это означает предсказуемее, проще диагностировать и меньше магии на загруженных узлах.
3) Делегирование: почему v2 легче «жить с systemd»
Одна из причин миграции экосистемы на v2 — более строгая и понятная модель делегирования поддеревьев. В реальной эксплуатации это выражается так: systemd, контейнерный runtime и kubelet проще согласовать, чтобы они не «перетягивали» управление процессами и лимитами друг у друга.
4) Метрики: меняются пути, имена файлов и смысл показателей
При переходе на v2 обычно меняется сразу три вещи:
- пути файлов в
/sys/fs/cgroup; - набор файлов (в v2 больше агрегированных статистик, меньше «россыпи» v1‑файлов);
- интерпретация некоторых показателей (особенно вокруг memory pressure/oom и учёта кэша).
Из-за этого после миграции часто «ломаются» самописные экспортеры, старые версии агентов мониторинга и алерты, жёстко привязанные к v1‑путям.
Как понять, что у вас: cgroup v1 или cgroup v2
На хосте начните с проверки типа файловой системы для /sys/fs/cgroup и списка монтирований:
mount | grep cgroup
stat -fc %T /sys/fs/cgroupЕсли в выводе второй команды видите cgroup2fs — это cgroup v2. Если видите несколько монтирований cgroup по разным контроллерам — это обычно v1.
Ещё один практичный признак v2 — наличие файлов cgroup.controllers и cgroup.subtree_control в дереве /sys/fs/cgroup.
systemd unified hierarchy: почему это важно именно для контейнерных хостов
В режиме unified hierarchy systemd управляет единым деревом cgroup v2 и раскладывает процессы сервисов по slice’ам. В контейнерном мире это важно из-за согласования «кто создаёт cgroup и где живут процессы».
На практике unified hierarchy обычно даёт:
- меньше конфликтов между systemd и контейнерным runtime;
- более понятную диагностику по дереву cgroup;
- меньше сюрпризов при лимитах и QoS, если kubelet/runtime тоже используют systemd‑драйвер.
Если вы ограничиваете ресурсы не только контейнерам, но и системным сервисам (например, отдельно «прижать» тяжёлый воркер или выделить slice под базу), полезно понимать механику systemd‑slice’ов и делегирования. По этой теме см. практический разбор: systemd cgroup и slices на примере сервисов.
Docker на cgroup v2: что проверить в первую очередь
1) Не смешивайте драйверы управления cgroup
На системах с systemd почти всегда разумнее, чтобы Docker использовал systemd‑драйвер. Тогда дерево процессов Docker будет согласовано с остальной системой, и диагностика станет проще.
Проверка режима Docker:
docker info | grep -E "Cgroup|Driver"Нормальная картина для «современного» хоста: cgroup v2 включён, а cgroup driver указан как systemd (формулировки зависят от версии Docker).
2) CPU/Memory: меньше «странностей», но метрики придётся обновить
Типичная история на v1: лимит памяти вроде выставлен, а OOM проявляется неожиданно; CPU при конкуренции распределяется «не так, как ожидали»; часть метрик — про одно, а алерты — про другое. На v2 многие углы сглажены, но плата за это — переход на новые файлы и семантику статистик.
3) IO‑контроль: тестируйте на своей storage‑цепочке
Если вы реально используете ограничения диска (например, чтобы снизить эффект «шумных соседей»), v2 даёт более цельную модель. Но итог зависит от типа диска, планировщика, слоёв хранения (включая overlayfs). Поэтому любые ожидания по I/O лучше подтверждать нагрузочными тестами на конкретном узле.
Kubernetes: kubelet cgroup driver как главный источник проблем после апдейтов
Самый частый сценарий поломок после обновления нод — рассинхрон между kubelet и container runtime по способу управления cgroup. Если один работает через systemd, а другой — через cgroupfs, процессы оказываются в неожиданных местах дерева, часть лимитов применяется «не туда», а диагностика начинает врать.
Что проверить на ноде: kubelet и runtime
Убедитесь, что стек согласован:
- хост работает в ожидаемом режиме cgroup (v1 или v2);
- kubelet настроен на systemd‑драйвер;
- containerd настроен на systemd‑cgroup.
Для containerd часто достаточно быстро проверить наличие включения systemd‑режима:
containerd config dump | grep -i systemdcgroupОриентир для конфигурации containerd (фрагмент для понимания):
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = trueПосле изменения настроек обычно нужен перезапуск containerd и kubelet. На проде делайте это через обычный процесс обслуживания нод (cordon/drain), чтобы не устроить «самопроизвольный» даунтайм.
cgroup v2 и QoS: где чаще всего удивляются
Kubernetes использует cgroup для реализации requests/limits, QoS‑классов (Guaranteed/Burstable/BestEffort) и поведения при давлении ресурсов. На v2 это чаще работает более согласованно, но типичные «сюрпризы» такие:
- иначе проявляется memory pressure (и, как следствие, ваши eviction‑пороги);
- метрики памяти могут выглядеть выше из‑за более честного учёта (включая кэш), и старые алерты становятся шумными;
- самописные проверки в нодовых скриптах ломаются из‑за смены путей и файлов.
Метрики и наблюдаемость: что ломается при переходе на v2 и как подготовиться
1) Самописные сборщики метрик
Если вы читали v1‑пути вроде /sys/fs/cgroup/cpu/cpuacct.usage, то в v2 их не будет. Придётся перейти на v2‑файлы (например, cpu.stat, cpu.max, memory.current) и пересчитать математику.
2) Агенты мониторинга и exporters
Даже в 2026 встречаются легаси‑агенты, которые ожидают v1. Перед миграцией проверьте версии node‑exporter/cAdvisor/агента вашей системы мониторинга и то, как именно они читают cgroup‑статистики.
3) Смысл алертов
Самая неприятная проблема: метрики могут «собираться», но поменять смысл. Алерт вида «memory usage > 90% 5 минут» после миграции может стать заметно более шумным. Это не всегда означает регрессию: иногда вы просто впервые видите реальную картину. В любом случае пороги и условия алертов стоит пересмотреть.
Типовые сценарии миграции: как действовать без сюрпризов
Сценарий A: новые ноды — сразу cgroup v2
Самый простой путь — не переключать «на месте», а заводить новые хосты уже на v2:
- оставляете unified hierarchy как есть;
- настраиваете runtime на systemd‑cgroup;
- настраиваете kubelet на systemd‑драйвер;
- прогоняете пилот (канарейка) и проверяете лимиты/метрики/eviction.
Минус подхода: возможен смешанный кластер (часть нод v1, часть v2). Это допустимо, но требует дисциплины в диагностике и одинаковых версий агентов наблюдаемости на всех нодах.
Сценарий B: переключение существующих нод с v1 на v2
Рискованнее, но выполнимо, если идти по шагам:
- Обновите runtime/kubelet/агенты мониторинга до версий, корректно работающих с v2.
- Выберите одну ноду‑«канарейку»: cordon/drain, переключение, возврат в кластер.
- Проверьте: лимиты CPU/memory, eviction, события OOM, метрики, стабильность storage и сетевых плагинов.
- Раскатывайте постепенно, фиксируя изменения в IaC/документации.
Главное правило миграции: сначала совместимость стека и наблюдаемости, потом переключение иерархии. Иначе вы «ослепнете» ровно в момент, когда метрики нужны сильнее всего.
Чек-лист диагностики: если после перехода на cgroup v2 «что-то не так»
1) Подтвердите реальный режим cgroup
stat -fc %T /sys/fs/cgroup
mount | grep cgroup2) Проверьте согласованность systemd/runtime/kubelet
ps -p 1 -o comm=
docker info | grep -E "Cgroup|Driver"
containerd config dump | grep -i systemdcgroup3) Убедитесь, что метрики читаются из правильных мест
Если у вас есть кастомные экспортеры/скрипты, явно зафиксируйте:
- какие v1‑пути вы читали ранее;
- на какие v2‑файлы вы их заменили;
- какая формула пересчёта используется (особенно для CPU‑времени и memory usage).
Хорошая практика — держать это в репозитории рядом с инфраструктурой (IaC), чтобы следующий апдейт не превратился в археологию.
Что выбирать в 2026: оставаться на v1 или переходить на v2
- Выбирайте cgroup v2, если у вас современные дистрибутивы, systemd, актуальные Docker/containerd и Kubernetes, и вы готовы обновить мониторинг/агентов под новые метрики.
- Оставайтесь на cgroup v1 временно, если вы жёстко завязаны на легаси‑агенты/метрики, у вас старые ядра или есть компоненты, которые документированно требуют v1. Но фиксируйте это как техдолг с планом выхода.
Для новых проектов или обновляемых узлов стратегически более устойчивый вариант — unified hierarchy и cgroup v2: меньше неоднозначностей, лучше делегирование, аккуратнее контроллеры CPU/Memory/IO и проще поддерживать предсказуемое поведение лимитов на плотных нодах. Если вы планируете выносить контейнерные нагрузки на отдельные серверы, обычно удобнее начинать с VDS, где вы контролируете ядро, systemd и настройки runtime без сюрпризов от соседних окружений.
Итог
Разница между cgroup v1 и cgroup v2 для Docker и Kubernetes — это не про «старое/новое», а про модель: единая иерархия, согласование systemd и runtime, более чёткие интерфейсы контроллеров и необходимость по‑взрослому подходить к метрикам. Планируя обновления хостов/кластеров, закладывайте время на проверку kubelet/runtime, перенос метрик и пересмотр алертов — это окупается стабильностью и понятной диагностикой.
