Kubernetes 운영 환경에서 자주 발생하는 장애 중 하나가 OOMKilled입니다.

Application이 정상적으로 실행되고 있다가 갑자기 종료되고 재시작되는 경우, Memory 부족이 원인일 수 있습니다.

예:

Application 실행

↓

Memory 사용량 증가

↓

Node Memory 부족

↓

Linux Kernel OOM 발생

↓

Container 강제 종료

Kubernetes는 이러한 상황을 감지하고 Container 종료 이유를 OOMKilled 상태로 표시합니다.

상태	의미
OOMKilled	Memory 부족으로 Container 종료
CrashLoopBackOff	Container 반복 재시작
Evicted	Node Resource 부족으로 Pod 제거
Pending	Resource 부족으로 실행 불가

OOMKilled 구조를 이해하면 Application 성능 문제와 Kubernetes Resource 문제를 빠르게 분석할 수 있습니다.

Kubernetes OOMKilled가 발생하는 이유

Container는 실행될 때 사용할 수 있는 Memory 범위가 정해집니다.

구조:

Container 실행

↓

Memory 사용 증가

↓

Memory Limit 초과

↓

Kubernetes 종료

주요 원인:

• Memory Limit 부족
• Application Memory Leak
• 잘못된 JVM 설정
• 대량 Request 증가
• Cache 증가

Application과 Infrastructure 양쪽을 확인해야 합니다.

Kubernetes Resource Request와 Limit 관계

Kubernetes에서는 Container Resource를 두 가지 방식으로 관리합니다.

Resource Request

Container 실행에 필요한 최소 Resource

예:

CPU 500m

Memory 512Mi

Scheduler가 Node 선택 기준으로 사용합니다.

Resource Limit

Container가 사용할 수 있는 최대 Resource

예:

Memory 1Gi

초과:

↓

OOMKilled 가능

두 설정을 정확히 이해해야 합니다.

Kubernetes OOMKilled 동작 과정

실제 흐름:

Application 요청 증가

↓

Memory 사용량 증가

↓

Limit 도달

↓

Container Runtime 감지

↓

Container 종료

↓

Restart 발생

↓

Pod 상태 변경

장애 상황에서는 Restart Count 확인이 중요합니다.

Kubernetes OOMKilled 확인 방법

Pod 상태 확인:

kubectl get pods

결과:

NAME        STATUS
web-app     CrashLoopBackOff

상세 확인:

kubectl describe pod pod-name

확인:

Reason: OOMKilled

종료 원인을 확인할 수 있습니다.

Kubernetes OOMKilled와 CrashLoopBackOff 차이

두 상태는 자주 함께 발생합니다.

구분	OOMKilled	CrashLoopBackOff
원인	Memory 초과	반복 종료
대상	Container 종료 이유	Pod 상태
해결	Memory 분석	Application 분석

OOMKilled가 원인이 되고 CrashLoopBackOff가 결과로 나타날 수 있습니다.

Kubernetes Memory 사용량 확인 방법

현재 사용량:

kubectl top pods

Node 확인:

kubectl top nodes

상세 정보:

kubectl describe pod pod-name

Resource 상태를 확인합니다.

Kubernetes Memory Leak 문제

Memory Leak은 대표적인 OOM 원인입니다.

구조:

Application 실행

↓

Memory 할당

↓

사용 완료

↓

Memory 반환 실패

↓

사용량 계속 증가

↓

OOM 발생

예:

• Java Heap 증가
• Cache 정리 실패
• 객체 참조 유지

Application Code 분석이 필요합니다.

Kubernetes JVM Application OOM 관리

Java Application은 별도 관리가 필요합니다.

문제:

Container Memory:

2GB

JVM Heap:

2GB

↓

JVM 외부 Memory 사용

↓

Limit 초과

해결:

Heap 크기 조정

예:

-Xmx1024m

Container Memory와 JVM 설정을 맞춰야 합니다.

Kubernetes OOMKilled 해결 방법

방법 1. Memory Limit 증가

기존:

Memory Limit:

512Mi

변경:

Memory Limit:

2Gi

Application 요구량에 맞게 조정합니다.

방법 2. Application 최적화

확인:

• Memory Leak
• 불필요한 Cache
• Object 관리

Code 개선이 필요합니다.

방법 3. Resource Monitoring

지속적으로 확인:

• Memory Trend
• Request 증가
• Peak Usage

사전 대응이 가능합니다.

Kubernetes LimitRange 활용

Namespace 단위 기본 Resource 정책을 설정할 수 있습니다.

예:

개발자가 Resource 설정을 누락해도 기본값 적용

구조:

Namespace

↓

LimitRange

↓

Pod 기본 Resource 적용

운영 환경 관리에 유용합니다.

Kubernetes ResourceQuota와 OOM 예방

ResourceQuota는 Namespace 전체 Resource 사용량을 제한합니다.

예:

Development Namespace

↓

Memory 최대 20GB

↓

초과 방지

여러 팀이 사용하는 Cluster에서 중요합니다.

Kubernetes Eviction과 OOMKilled 차이

비슷하지만 다릅니다.

OOMKilled:

Container 자체 Memory Limit 초과

Eviction:

Node 전체 Resource 부족

비교:

구분	OOMKilled	Eviction
대상	Container	Pod
원인	Limit 초과	Node 부족
처리	Container 종료	Pod 제거

Kubernetes OOMKilled 장애 대응 순서

실제 운영 과정:

1단계

상태 확인

kubectl describe pod

↓

2단계

Memory 사용 확인

kubectl top pods

↓

3단계

Limit 확인

kubectl get pod -o yaml

↓

4단계

Application 분석

↓

5단계

Resource 조정

원인을 찾아 해결합니다.

Kubernetes OOMKilled 예방 전략

Production 환경에서는:

Memory Monitoring

↓

적절한 Limit 설정

↓

Application Profiling

↓

Alert 설정

↓

자동 대응

사전 예방이 중요합니다.

Kubernetes OOMKilled와 Observability 관계

Observability 환경에서는:

Metric:

Memory 증가 확인

↓

Log:

Application Error 확인

↓

Trace:

특정 Request 분석

세 데이터를 함께 활용합니다.

Kubernetes OOMKilled 장점 있는 관리 구조

적절한 Resource 관리는:

• Node 안정성 증가
• 서비스 장애 감소
• 비용 최적화
• 성능 개선

으로 연결됩니다.

자주 묻는 질문

OOMKilled가 발생하면 Pod가 삭제되나요?

대부분 Container가 재시작되며 Pod 자체는 유지됩니다.

Memory Limit을 크게 설정하면 해결되나요?

일시적으로 해결될 수 있지만 Memory Leak이면 근본 해결이 필요합니다.

Request와 Limit 중 무엇이 더 중요한가요?

둘 다 중요합니다.

Request는 Scheduling, Limit은 Resource 보호 역할을 합니다.

마무리

Kubernetes OOMKilled는 Container가 설정된 Memory 제한을 초과하여 강제 종료되는 대표적인 장애 상황입니다.

확인 항목	역할
kubectl describe	장애 원인 확인
kubectl top	Memory 사용량 확인
Resource Limit	사용 제한 관리
Application 분석	근본 원인 해결

OOMKilled 분석 방법을 이해하면 Kubernetes 환경에서 Memory 장애를 빠르게 해결하고 안정적인 서비스를 운영할 수 있습니다.

다음 글에서는 Container 반복 장애 원인을 분석하는 Kubernetes CrashLoopBackOff 완벽 가이드! Pod 반복 재시작 원인과 해결 방법 이해하기를 진행하겠습니다.