통합 계층이 뜻하는 것

Linux cgroup v2는 프로세스의 자원 사용량을 계층적으로 제한·계량하는 커널 인터페이스다. v1처럼 컨트롤러마다 별도 계층을 마운트하는 대신 통합된 계층을 제공하지만, 모든 컨트롤러가 모든 커널에서 자동 활성화된다는 뜻은 아니다. 루트 계층의 cgroup.controllers, 하위 계층의 cgroup.subtree_control, 마운트 옵션과 커널 설정을 확인해야 한다. CPU·메모리·I/O 제어 파일과 세부 동작은 커널 버전과 컨트롤러 지원 여부에 따라 다르다.

systemd에서의 작성자와 위임

systemd 프로젝트의 제어 그룹 인터페이스 문서는 cgroup v2의 각 계층을 한 사용자 공간 구성요소가 관리하는 단일 작성자 모델로 설명한다. systemd가 PID 1인 호스트에서는 임의로 cgroup 파일을 직접 고치지 말고 systemd unit의 자원 속성을 쓰는 것이 기본 경로다. 서비스가 자체 하위 cgroup을 관리해야 한다면 해당 unit에 Delegate=yes 같은 명시적 위임을 설정하고 허용된 하위 트리만 다룬다. 다른 런타임이나 init 체계에서는 그 관리자 문서와 권한 경계를 따로 확인해야 한다.

컨트롤러별 의미를 구분

cpu.max, memory.max, io.max 등은 서로 다른 정책을 표현하며, 제한을 설정했다고 애플리케이션의 체감 성능이나 공정성이 자동 보장되는 것은 아니다. I/O 제어의 지원 범위와 실제 적용은 블록 장치·파일시스템·커널 구성에 좌우될 수 있다. cgroup v2의 도메인 컨트롤러에서는 하위 계층에 컨트롤러를 활성화할 때 내부 프로세스가 있는 부모에 관한 제약이 적용된다. 이를 모든 cgroup 작업의 보편적 금지로 확대하면 threaded subtree 같은 모델을 놓친다.

PSI와 OOM은 별도 기능 조합

Pressure Stall Information은 커널이 CPU·메모리·I/O 압력으로 작업이 지연된 시간을 관찰하도록 하는 인터페이스이며 cgroup v2와 함께 읽을 수 있다. some과 full의 평균·누적 값은 서로 다른 의미이므로 단일 “사용률” 숫자로 취급하지 않는다. 파일 노출 여부와 구성은 커널 및 설정을 확인한다. systemd-oomd는 PSI 기반 판단을 활용할 수 있지만, 이것이 모든 배포판이나 Kubernetes 노드가 같은 방식으로 컨테이너를 종료한다는 뜻은 아니다. kubelet의 메모리 압박 축출, 커널 OOM, 사용자 공간 oomd 정책을 구분한다.

전문가의 전환 경험과 적용

컨테이너 분야 실무자인 Red Hat의 Dan Walsh는 cgroup v2 전환 당시 컨테이너 도구와 배포판의 호환성 문제가 기본 활성화를 늦췄고, Fedora와 Podman·CRI-O·crun의 연동 작업이 필요했다고 회고한다. 이는 특정 시기의 생태계 경험이지 현재 모든 배포판에 대한 호환성 표는 아니다. 운영 전 호스트의 실제 모드, 커널 파일, systemd 및 런타임 버전, 컨테이너별 제한 적용 결과를 검증하고 v1 경로와의 차이를 테스트한다.

참고 자료