Kubernetes v1.35부터 기본 설정의 kubelet은 cgroup v1 노드에서 시작하지 않습니다. 업그레이드할 리눅스 노드에서 cgroup 모드를 확인하고, v1이 남아 있다면 런타임과 운영 에이전트의 호환성까지 검증한 뒤 전환 일정을 잡으세요.
v1.35에서 무엇이 달라졌나
서버를 재부팅한 뒤 kubelet이 올라오지 않으면 그 노드는 워크로드를
정상적으로 운영하기 어렵습니다. Kubernetes v1.35에서 달라진 점은
kubelet의 failCgroupV1 기본값입니다. 기본값이
true이므로 cgroup v1을 사용하는 리눅스 노드에서 kubelet
시작이 차단됩니다. API 서버 버전과 함께 각 노드에 설치할 kubelet
버전과 실제 적용 설정을 확인해야 하는 이유입니다. K1 · K3
failCgroupV1: false는 해당 옵션을 지원하는 버전에서
kubelet의 시작 차단을 해제하는 임시 설정입니다. cgroup v2를 활성화하는
설정은 따로 준비해야 합니다. 이 예외를 써야 한다면 적용할 노드와 제거
시점을 변경 기록에 남겨 두는 편이 후속 업그레이드를 계획하기
쉽습니다.
노드에서 cgroup 버전 확인하기
kubelet이 실행되는 리눅스 노드에서 아래 명령을 실행합니다. VM이 노드라면 VM 안에서 실행하세요. 노드 풀이 여러 개라면 오래된 이미지로 만들어진 노드가 남아 있을 수 있으므로, 이번에 업그레이드할 노드별로 결과를 기록합니다. K2
stat -fc %T /sys/fs/cgroup/| 출력 | 해석 | 다음 확인 |
|---|---|---|
cgroup2fs |
cgroup v2 | 커널, 컨테이너 런타임, kubelet과 런타임의 systemd 드라이버 설정을 점검 |
tmpfs |
공식 문서의 cgroup v1 판정값 | 목표 kubelet 버전을 확인하고 v2 노드 이미지나 OS 전환 절차를 준비 |
| 명령 실패 또는 기타 값 | 현재 출력으로 판정 보류 | 실행 위치, 경로와 마운트 구성 확인 |
사전검사와 노드 전환은 어떻게 준비할까?
kubeadm을 쓴다면 사전검사 결과를 따로 보세요.
Kubernetes 프로젝트 설명에 따르면 SystemVerification은
cgroup v1 노드에서 kubelet v1.35 이상을 감지하면
kubeadm init, join, upgrade
과정에서 오류를 반환합니다. 이전 kubelet에서는 경고로 처리됩니다.
kubelet의 시작 예외와 kubeadm의 사전검사는 서로 다른 확인 지점입니다.
관리형 Kubernetes에서 공급자가 노드 이미지를 제어한다면 해당 공급자의
업그레이드 경로를 확인하세요. K1
먼저 테스트 노드 하나에서 전환을 확인하세요. 공식 문서가 제시하는 v2 요건에는 cgroup v2가 활성화된 OS, Linux 5.8 이상, v2 지원 컨테이너 런타임, kubelet과 런타임의 systemd cgroup 드라이버가 포함됩니다. cgroup 파일을 직접 읽는 모니터링·보안 에이전트도 버전 호환성을 확인합니다. K2
검증 결과를 남길 때는 노드 이름, OS 이미지, kubelet과 런타임 버전, 명령 출력, 테스트 결과를 한 줄로 묶으세요. 예를 들어 테스트 노드가 정상 등록된 뒤 대표 워크로드가 기동되는지, CPU·메모리 지표와 경보가 계속 수집되는지 확인합니다. 같은 이미지와 설정의 노드를 순차적으로 전환하더라도 각 노드에서 cgroup 모드와 기동 결과를 기록하세요. 구성이나 에이전트 버전이 다르면 별도 테스트 대상으로 분리합니다.
