CS Insights

리눅스 cgroups v2를 활용한 쿠버네티스 OOM 킬(Kill) 방어와 계층적 자원 통제의 미학

리눅스 cgroups v2를 활용한 쿠버네티스 OOM 킬(Kill) 방어와 계층적 자원 통제의 미학
쿠버네티스(Kubernetes) 환경에서 아무리 Pod의 메모리 리밋(Limits) 설정을 보수적으로 주어도, 메모리를 급격히 빨아들이는 AI 모델의 인퍼런스 컨테이너 하나가 노드 전체의 커널 여유분 메모리 수압을 붕괴시켜 다른 선량한 컨테이너들까지 줄줄이 OOM(Out of Memory) KILLED 당하는 연쇄 재앙을 수차례 겪었습니다. 이 밑바닥에는 리눅스의 낡은 컨테이너 격리 기술인 커널 cgroup v1 아키텍처의 한계가 숨어있었습니다. cgroup v1은 CPU, 메모리, 블록 I/O 등의 자원 컨트롤러 모듈들이 각기 독립적인 계층 트리를 가지고 파편화되어 동작합니다. 메모리가 부족해지면 I/O 컨트롤러가 즉각 스로틀링을 인지하지 못하고 디스크 백업을 지속하다가 커널 패닉을 앞당기는 구조적 모순이 존재했습니다. 또한 여유 메모리가 바닥을 칠 무렵 '사전 경고' 없이 그냥 가장 덩치가 큰 프로세스의 목을 날려버리는 OOM Killer의 잔혹함도 통제할 수 없었습니다. 이 시스템 레벨의 무질서를 재건하기 위해, 저희는 워커 노드의 구동 커널 스펙을 올려 cgroups v2 통합(Unified) 계층을 쿠버네티스 런타임에 전면 활성화했습니다. v2에서는 모든 자원 컨트롤러가 단 하나의 오가닉(Organic)한 계층 폴더 구조 상에 묶이게 됩니다. 특히 v2가 지원하는 `memory.high` 와 `memory.max` 의 이원화 플래그는 구원줄이 되었습니다. 하드 리밋(max)을 치고 프로세스가 즉사하기 전, 소프트 리밋(high) 경계선에 컨테이너 메모리가 도달하면 커널이 미리 프로세스 스케줄링을 강제로 늦춰 메모리 반환 여유를 주는 Pacing(제동) 로직이 살아난 것입니다. 이를 통해 이웃 컨테이너가 죽어나가는 연쇄 폭파 현상을 완전히 소거할 수 있었고, 리드미컬한 워크로드 제어 권력을 OS 레이어로부터 돌려받을 수 있었습니다.

Related Posts