infra

쿠버네티스 OOMKilled·Evicted 트러블슈팅: Node 장애까지 한 번에 정리

mirabo01 2026. 2. 10. 09:54

쿠버네티스 실전 트러블슈팅, OOMKilled · Evicted · Node 장애 대응 정리

앞선 글에서는 Pod가 뜨지 않을 때의 기본적인 확인 순서를 정리했다.
이번에는 운영 중 실제로 가장 자주 마주치는 조금 더 실전적인 에러들을 다룬다.

  • Pod가 갑자기 재시작되며 OOMKilled가 찍힌다
  • 아무 설정도 안 바꿨는데 Pod가 Evicted 상태가 된다
  • 특정 Node에서만 문제가 반복된다

이런 케이스들은 단순한 설정 오류를 넘어서
리소스와 클러스터 상태를 함께 봐야 하는 문제다.

OOMKilled: 가장 흔한 메모리 관련 장애

OOMKilled는 이름 그대로다.

컨테이너가 메모리 limits를 초과해 강제로 종료된 상태

이 상태는 로그를 보지 않아도
kubectl describe pod에서 바로 확인할 수 있다.

Reason: OOMKilled

[이미지: OOMKilled 상태가 표시된 Pod describe 예시]

OOMKilled가 발생하는 대표적인 원인

1. 메모리 limits가 너무 작은 경우

가장 흔한 케이스다.

  • requests는 적당히 설정
  • limits를 과하게 작게 설정

특히 다음 상황에서 자주 발생한다.

  • JVM 기반 애플리케이션
  • 초기 로딩 시 메모리 사용량이 큰 서비스
  • 캐시를 사용하는 애플리케이션

실제로 써보면
“평소에는 괜찮다가 특정 타이밍에만 죽는” 패턴이 많다.

2. 메모리 누수 또는 비정상 사용

limits를 충분히 줬는데도 OOMKilled가 난다면
애플리케이션 자체를 의심해야 한다.

  • GC가 제대로 동작하지 않는 경우
  • 특정 요청에서 메모리를 과도하게 사용하는 경우

이때는 단순히 limits를 늘리는 것보다
메모리 사용 패턴을 확인하는 게 먼저다.

Evicted: Node가 Pod를 쫓아내는 상황

Evicted는 Pod 자체의 문제가 아닐 수도 있다.

Node가 리소스 압박 상태가 되면서 Pod를 강제로 제거한 경우

대표적인 트리거는 다음과 같다.

  • Node 메모리 부족
  • 디스크 압박
  • 임시 스토리지 부족

[이미지: Node 리소스 압박으로 Pod가 Evicted되는 흐름]

Evicted가 발생했을 때 확인 순서

1. Pod 이벤트 확인

kubectl describe pod <pod-name>

이벤트에 보통 이런 메시지가 나온다.

  • The node was low on resource: memory
  • The node had disk pressure

이 메시지를 보면
“Pod 설정 문제인지, Node 문제인지”가 갈린다.

2. 같은 Node의 다른 Pod 상태 확인

  • 같은 Node에 있던 Pod들이 연쇄적으로 사라졌는지
  • 특정 워크로드만 반복적으로 Evicted되는지

여러 Pod가 동시에 영향을 받았다면
거의 확실하게 Node 레벨 문제다.

Node 장애: 가장 범위가 큰 문제

Node 장애는
개별 Pod 트러블슈팅과 접근 방식이 다르다.

다음 징후가 보이면 Node를 의심해볼 필요가 있다.

  • Node 상태가 NotReady
  • 특정 Node에만 Pod 장애가 집중됨
  • 네트워크 타임아웃이 반복됨
kubectl get nodes

여기서 상태가 비정상이라면
Pod 레벨에서 아무리 봐도 답이 안 나온다.

Node 장애 시 기본 대응 흐름

실무에서 많이 사용하는 접근은 다음과 같다.

  1. Node 상태 확인
  2. 해당 Node에 있는 Pod 목록 확인
  3. Pod 재스케줄링 여부 확인
  4. Node 격리 또는 재시작

쿠버네티스의 장점은
Node 하나가 문제가 생겨도
다른 Node로 Pod를 옮길 수 있다는 점이다.

다만, StatefulSet이나
Node에 의존적인 워크로드는
영향이 더 크게 나타날 수 있다.

트러블슈팅에서 자주 하는 실수

운영하면서 자주 보게 되는 패턴이다.

  • OOMKilled인데 무작정 limits만 늘림
  • Evicted인데 Pod 설정만 계속 수정함
  • Node 문제인데 Pod 로그만 계속 봄

이런 경우는
문제를 “한 단계 위에서” 봐야 한다.

Pod → Node → Cluster
이 흐름을 왔다 갔다 할 수 있어야 한다.

장애를 줄이기 위한 사전 포인트

완벽한 예방은 어렵지만,
다음만 지켜도 장애 빈도가 꽤 줄어든다.

  • 메모리 limits는 여유 있게
  • Node 리소스 모니터링 필수
  • Eviction 이벤트 알람 설정
  • 특정 Node에 워크로드 쏠림 방지

실제로 운영해보면
트러블슈팅보다 사전 감지가 훨씬 중요하다는 걸 느끼게 된다.

정리하며

이번 글에서는 쿠버네티스 운영 중
가장 자주 마주치는 실전 트러블슈팅 케이스를 정리했다.

  • OOMKilled는 대부분 메모리 문제다
  • Evicted는 Node 리소스 압박 신호다
  • Node 장애는 Pod만 봐서는 해결되지 않는다

다음 글에서는
이 트러블슈팅을 줄이기 위한 관점에서
쿠버네티스 운영 시 설계와 습관,
즉 “처음부터 덜 아프게 운영하는 방법”을 정리해볼 예정이다.