cgroups v2 en el host: comprobar el modo y leer los límites de recursos por unidad

Objetivo

Confirmar en qué modo de cgroup se está ejecutando un host Linux e inspeccionar los límites de recursos que systemd (y, a través de él, los runtimes de contenedores) aplican a una unidad o un contenedor concreto.

Requisitos previos

Acceso a la shell; no se requiere root para la inspección de solo lectura, pero sí para ver los detalles de cgroup de otros usuarios.

Pasos

1. Comprobar el modo: stat -fc %T /sys/fs/cgroup. La documentación de cgroup v2 del kernel monta la jerarquía unificada como el tipo de sistema de archivos cgroup2, que stat muestra como cgroup2fs; esa salida significa que el host está totalmente en cgroup v2 (modo unificado). Ver en cambio tmpfs significa una configuración híbrida o heredada (cgroup v1), en la que /sys/fs/cgroup es un tmpfs con montajes de controladores v1 independientes por debajo.
2. Explorar el árbol como una jerarquía de slices, scopes y servicios: systemd-cgls imprime todo el árbol de cgroups con los procesos bajo cada unidad; systemd-cgls /system.slice/docker.service (o el slice correspondiente) lo restringe a una sola rama.
3. Observar el uso de recursos en vivo por cgroup: systemd-cgtop muestra tareas, CPU, memoria y E/S por grupo de control, actualizándose como top; útil para detectar qué contenedor o servicio está consumiendo los recursos de un host sin conocer de antemano su PID.
4. Leer directamente los límites configurados de una unidad de systemd: systemctl show <unit> --property=MemoryMax,MemoryHigh,CPUQuotaPerSecUSec. Un contenedor Podman Quadlet se ejecuta bajo su unidad de servicio; un contenedor docker run --memory=512m con el controlador de cgroup de systemd (el valor por defecto habitual en cgroup v2) se convierte en un docker-<id>.scope bajo system.slice — con el controlador cgroupfs, en cambio, queda bajo /sys/fs/cgroup/docker/<id>/. En cualquiera de los dos casos, leer memory.max y cpu.max en ese directorio para obtener los valores brutos aplicados por el kernel (max significa sin límite).
5. Relacionar un contenedor con su ruta de cgroup: systemctl status <container-unit> (gestionado por Quadlet/systemd), o tomar el PID principal del contenedor (docker inspect --format '{{.State.Pid}}' <container>) y leer /proc/<pid>/cgroup, cuya única línea 0::<path> en cgroup v2 es la ruta relativa a /sys/fs/cgroup. (.HostConfig.CgroupParent suele estar vacío; solo muestra un padre establecido explícitamente).

Resultado esperado

stat -fc %T /sys/fs/cgroup indica cgroup2fs; systemd-cgtop y systemd-cgls muestran el árbol de unidades esperado con cifras en vivo que coinciden con lo que el runtime de contenedores informa mediante sus propios comandos stats.

Límites y base de verificación

La ruta y los nombres exactos de los archivos de controlador (memory.max, cpu.max, etc.) son los nombres de la jerarquía unificada documentados en la guía de administración de cgroup v2 del kernel; un host que aún esté en el cgroup v1 heredado expone nombres de archivo distintos por controlador y controles de límites diferentes (memory.limit_in_bytes), que este artículo no trata.