cgroups v2 no host: verificar o modo e ler os limites de recursos por unidade

Objetivo

Confirmar em que modo de cgroup um host Linux está rodando e inspecionar os limites de recursos que o systemd (e, por intermédio dele, os runtimes de contêineres) aplica a uma unidade ou a um contêiner específico.

Pré-requisitos

Acesso a um shell. Não é preciso root para a inspeção somente leitura, mas ele é necessário para ver alguns detalhes de cgroups de outros usuários.

Passos

1. Verifique o modo: stat -fc %T /sys/fs/cgroup. Segundo a documentação de cgroup v2 do kernel, a hierarquia unificada é montada com o tipo de sistema de arquivos cgroup2, que o stat reporta como cgroup2fs; essa saída significa que o host está totalmente em cgroup v2 (modo unificado). Se aparecer tmpfs, a configuração é híbrida ou legada (cgroup v1): nesse caso /sys/fs/cgroup é um tmpfs, com montagens separadas dos controladores v1 por baixo.
2. Navegue pela árvore como uma hierarquia de slices, scopes e services: systemd-cgls mostra toda a árvore de cgroups com o(s) processo(s) de cada unidade; systemd-cgls /system.slice/docker.service (ou o slice relevante) restringe a saída a um único ramo.
3. Acompanhe o uso de recursos em tempo real por cgroup: systemd-cgtop mostra tarefas, CPU, memória e I/O por grupo de controle, com atualização contínua como o top; é útil para descobrir qual contêiner ou serviço está consumindo os recursos do host sem conhecer seu PID de antemão.
4. Leia diretamente os limites configurados de uma unidade systemd: systemctl show <unit> --property=MemoryMax,MemoryHigh,CPUQuotaPerSecUSec. Um contêiner Podman Quadlet roda sob a sua unidade de serviço; um contêiner iniciado com docker run --memory=512m e o driver de cgroup do systemd (o padrão habitual em cgroup v2) torna-se um docker-<id>.scope dentro de system.slice — com o driver cgroupfs, fica em /sys/fs/cgroup/docker/<id>/. Em ambos os casos, leia memory.max e cpu.max nesse diretório para obter os valores brutos impostos pelo kernel (max significa sem limite).
5. Relacione um contêiner ao seu caminho de cgroup: use systemctl status <container-unit> (para contêineres geridos por Quadlet/systemd) ou obtenha o PID principal do contêiner (docker inspect --format '{{.State.Pid}}' <container>) e leia /proc/<pid>/cgroup, cuja única linha 0::<path> em cgroup v2 contém o caminho relativo a /sys/fs/cgroup. (.HostConfig.CgroupParent normalmente está vazio; só mostra um pai definido explicitamente.)

Resultado esperado

stat -fc %T /sys/fs/cgroup reporta cgroup2fs; systemd-cgtop e systemd-cgls mostram a árvore de unidades esperada, com valores em tempo real que coincidem com o que o runtime de contêineres reporta por meio dos seus próprios comandos stats.

Limites e base de verificação

O caminho e os nomes exatos dos arquivos dos controladores (memory.max, cpu.max etc.) são os nomes da hierarquia unificada documentados no guia de administração de cgroup v2 do kernel. Um host que ainda usa cgroup v1 legado expõe nomes de arquivo diferentes, por controlador, e outros parâmetros de limite (memory.limit_in_bytes), que este artigo não cobre.