Kubernetes 공식 블로그가 cgroup v1 지원 축소와 v2 전환 시 확인할 사항을 정리했습니다. cgroup은 Linux의 자원 제어 기능입니다. Kubernetes 1.35부터 기본 설정에서는 cgroup v1 노드의 kubelet이 시작하지 않는다는 점을 특히 짚었습니다. Kubernetes 공식 발표
같은 클러스터에 서로 다른 OS 이미지나 런타임 설정의 노드가 섞여 있을 수 있습니다. 제어 평면의 버전만 적어 두지 말고 노드별 OS, 커널, 런타임과 cgroup 구성을 연결해야 해요.
이 글의 목차
자원 요청이 실제 제한이 되기까지의 경로
파드의 CPU와 메모리 요청·제한은 Kubernetes 설정이지만, 실제 프로세스의 자원 사용을 제어하는 데에는 Linux 커널 기능이 사용됩니다. cgroup은 여러 프로세스를 묶어 자원을 계산하고 제한하는 기반입니다. kubelet과 컨테이너 런타임이 이 계층을 일관되게 관리해야 설정이 기대한 동작으로 이어집니다. 제어 평면 버전만 올리는 것으로 노드의 기반 구성이 바뀌지는 않습니다.
cgroup v2는 통합된 계층과 자원 제어 인터페이스를 제공합니다. 하지만 운영체제가 v2를 지원하는 것과 현재 부팅한 노드가 실제로 v2를 사용하는 것은 다릅니다. 부팅 설정이나 과거 이미지 때문에 다른 모드가 남을 수 있어요. 노드 풀에 새 이미지와 오래된 이미지가 섞여 있다면 노드별로 실제 상태를 확인해야 합니다.
kubelet이 시작하지 않으면 파드 조사보다 먼저 볼 것
kubelet은 노드에서 파드 실행을 관리하는 구성 요소입니다. 업그레이드 뒤 이 프로세스가 시작하지 않으면 앱의 로그만으로는 원인을 찾기 어렵습니다. 공식 글이 설명한 1.35의 기본 동작과 사전 검사를 확인하고, 노드 로그에서 cgroup 관련 거부인지 다른 설정 문제인지 구분합니다. 임시 예외는 적용 이유와 해제 계획을 남겨야 합니다.
또한 cgroup의 버전과 cgroup 드라이버는 다른 항목입니다. 드라이버는 kubelet과 런타임이 자원 계층을 관리하는 방식이며 서로 맞아야 합니다. v2 파일시스템이 보인다는 사실만으로 런타임과 드라이버 호환성까지 모두 확인됐다고 적지 않습니다. 지원하는 OS·커널·런타임 조합을 기준으로 노드 이미지를 관리합니다.
한 노드 풀을 바꾸며 비교할 동작
먼저 대표 노드에서 읽기 전용으로 파일시스템 종류를 확인합니다. 아래 명령 결과가 cgroup2fs라면 해당 위치에 cgroup v2 파일시스템이 마운트된 상태를 뜻합니다. 다른 결과가 나오면 호스트의 부팅·마운트 구성을 더 조사해야 합니다. 컨테이너 안에서 본 상태를 호스트 전체의 상태로 단정하지 말고 실제 노드에서 확인합니다.
전환 시험은 워크로드를 안전하게 이동할 여유 용량과 중단 조건을 정한 뒤 진행합니다. 전환 후 파드 기동과 메모리 지표, OOM과 축출, 모니터링 수집을 기존 상태와 비교합니다. 특히 cgroup 파일을 직접 읽는 에이전트나 스크립트는 새 경로를 이해하는지 살펴봅니다. 문제가 없다는 근거를 확보한 노드 이미지로 다음 노드 풀을 전환합니다.
stat -fc %T /sys/fs/cgroupcgroup2fs는 이 마운트 지점의 종류를 나타냅니다. kubelet 설정과 컨테이너 런타임의 드라이버·지원 조건은 별도로 확인해야 합니다. 여기서는 노드의 실제 출력이나 전환 성공을 주장하지 않습니다.
노드 한 대부터 확인할 값
- 호스트에서 cgroup 파일시스템 종류와 런타임 드라이버를 확인합니다.
- 업그레이드 대상 kubelet·kubeadm의 사전 검사 조건을 대조합니다.
- 노드별로 워크로드를 비우고 시험한 뒤 순차 전환합니다.
임시 예외 설정을 장기 해법으로 남기지 않습니다. 어떤 노드가 예외를 쓰는지와 종료 계획을 기록해야 다음 업그레이드에서 다시 막히지 않습니다.
발표문 기준일: 2026-10-06 · 확인일: 2026-10-24
