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 반복 재시작 원인과 해결 방법 이해하기를 진행하겠습니다.