기본 콘텐츠로 건너뛰기

라벨이 Node OOM 원인분석인 게시물 표시

Kubernetes 노드 OOM 반복 발생 — 원인 분석과 실무적 방지책

Kubernetes 노드 OOM 반복 발생 — 원인 분석과 실무적 방지책 AI 생성 이미지: Kubernetes 노드 OOM 반복 발생 원인과 방지책 문제 정의 — 노드 OOM이 반복 발생하면 어떤 문제가 생기는가 노드 수준에서 OOM(Out Of Memory)이 반복되면 단순한 메모리 누수를 넘어 심각한 운영 리스크로 이어진다. 커널의 OOM killer가 작동하고, kubelet이 강제로 파드를 퇴거시키며 파드 재시작과 CrashLoopBackOff가 잦아진다. 이로 인해 서비스 가용성과 데이터 일관성이 즉시 악화된다. 이후 섹션에서는 Kubernetes 노드 OOM 반복 발생 원인과 방지책을 중심으로 해결 방안을 제시한다. 증상: 커널 로그의 OOM 메시지, kubelet 이벤트의 "Evicted"/"OOMKilled" 기록, 파드 재스케줄링 빈도 상승, 노드의 NodeNotReady 상태 증가 직접 영향: 인메모리 캐시나 세션 등 임시 상태 손실로 데이터 일관성이 흔들리고, 그 결과 요청 실패와 응답 지연이 늘어난다. 운영 영향: 스케줄링 혼잡과 리소스 파편화가 발생한다. HPA나 클러스터 오토스케일러가 의도와 다르게 동작할 수 있고, 모니터링·알람의 폭주로 관제 피로가 커진다. 성능 영향: 가비지 컬렉션과(스왑 사용 시) 스왑 활동 증가로 I/O 대기와 전체 서비스 레이턴시가 악화된다. 실무 체크리스트: 파드별 메모리 요청·한계 확인, 노드별 OOM 발생률 수집 및 추세 분석, 문제 재현 시 메모리 프로파일링 우선 수행 OOM 내부 메커니즘 — Linux OOM killer와 K8s Eviction의 차이 Linux 커널의 OOM killer는 시스템 전체 메모리와 스왑이 고갈될 때 커널이 프로세스를 강제 종료해 시스템을 구하는 마지막 수단입니다. 선택 기준은 프로세스의 메모리 사용량, 우선순위 등 여러 휴리스틱을 따릅니다. kubelet과는 독립적으로 동작하므로 갑작스럽고...