Поддержка cgroup v1 Kubernetes фактически отправлена на пенсию: начиная с версии 1.35 параметр kubelet failCgroupV1 по умолчанию включён. Если узел всё ещё работает на старой иерархии control groups, kubelet не инициализируется без явного исключения в конфигурации. Для команд, которые планируют обновление кластеров, это не косметическая депрекация, а повод проверить каждый node pool до того, как CI/CD внезапно останется без воркеров.
О переходе экосистемы на cgroup v2 сообщает The New Stack. Формулировка «cgroup v1 умер» звучит громче, чем текущий статус в коде Kubernetes: временный обходной путь пока существует, а окончательное удаление поддержки отложено до одного из будущих релизов. Но направление уже не вызывает сомнений: cgroup v1 больше не развивают, новые возможности Kubernetes ориентированы на вторую версию механизма.
cgroups — механизм ядра Linux, которым контейнерная платформа ограничивает и учитывает CPU, память, I/O и другие ресурсы процессов. Kubernetes использует его через kubelet и контейнерный runtime, чтобы превращать requests и limits из манифестов в реальные ограничения на ноде. В cgroup v1 контроллеры ресурсов существуют раздельно; cgroup v2 использует единую иерархию и даёт ядру более согласованную модель управления ресурсами.
Переход начался не вчера. Поддержка cgroup v1 была переведена в режим сопровождения в Kubernetes 1.31: критические регрессии ещё исправляют, но функционального развития ждать не приходится. В 1.35 значение failCgroupV1 сменили на true по умолчанию. Это означает простую, но неприятную механику апгрейда: control plane может обновиться штатно, однако старый Linux-хост на cgroup v1 не сможет поднять kubelet и выпадет из кластера.
В Kubernetes 1.37 временное исключение всё ещё доступно: администратор может установить failCgroupV1: false в конфигурации kubelet. Это не миграция и не способ «починить навсегда» — лишь отсрочка. Проект Kubernetes прямо рекомендует переносить узлы на cgroup v2, потому что дальнейшее удаление кода cgroup v1 остаётся в планах.
Причина не только в желании почистить технический долг. Современные дистрибутивы и базовые компоненты Linux уже уходят от старой схемы. systemd начал сворачивать поддержку cgroup v1 в версии 256; Red Hat объявлял cgroups v1 устаревшими в RHEL 9.4 и ориентирует RHEL 10 только на cgroup v2. Amazon Linux 2023 также не считает конфигурацию с v1 поддерживаемой. Kubernetes здесь не задаёт моду, а догоняет инфраструктурный слой, на котором работает.
Для платформенных команд важнее другое: часть возможностей Kubernetes доступна только при cgroup v2. В документации проекта среди таких сценариев фигурируют расширенное управление ресурсами, включая изменение ресурсов Pod без пересоздания и механизмы защиты памяти. Старый режим превращается в барьер не только для будущего обновления, но и для внедрения уже появившихся функций.
Практический план лучше начать с инвентаризации, а не с изменения флага. На каждой ноде нужно определить используемую версию cgroups, сверить режим загрузки ОС, версию systemd, runtime и образы, из которых собираются worker-ноды. Отдельно стоит проверить сторонние агенты: мониторинг, безопасность, сетевые плагины и старые Java- или Node.js-приложения нередко делают предположения о файловой структуре cgroup v1. Проблема может проявиться не в Kubernetes-манифесте, а внутри давно забытого DaemonSet.
Затем миграцию разумно прогнать на отдельном пуле: создать ноды с cgroup v2, перенести на них некритичные нагрузки, посмотреть на метрики памяти, OOM-события и поведение autoscaling. В cgroup v2 иначе устроены отдельные детали реакции на нехватку памяти, поэтому тест должен включать не только успешный запуск Pod, но и нагрузочные сценарии. В частности, команда должна заранее согласовать, какое поведение при OOM она ожидает от процесса и от всей группы процессов.
Для российских команд, использующих managed Kubernetes или собственные кластеры в дата-центрах, зона риска различается. В managed-сервисе образ узла и параметры загрузки часто определяет провайдер — там нужно выяснить, на какой версии cgroups работает конкретный пул и как обновляется его ОС. В self-managed-кластерах ответственность шире: проверить придётся шаблоны виртуальных машин, PXE-образы, Terraform-модули, Ansible-роли и инструкции для аварийного развёртывания. Иначе новый кластер будет жить на v2, а восстановленный «по старому плейбуку» — уже нет.
История с cgroup v1 Kubernetes хорошо показывает зрелость cloud-native стека: обратная совместимость имеет срок годности, особенно когда нижележащая ОС перестаёт поддерживать старый режим. Временный флаг даёт пространство для планирования, но не повод откладывать работу. Главный вопрос теперь не в том, удалят ли cgroup v1 из Kubernetes, а в том, успеет ли каждая команда найти зависимость от него до первого неудачного обновления.