infra

쿠버네티스 운영에서 반드시 봐야 할 모니터링 신호들

mirabo01 2026. 2. 23. 10:00

— 장애가 터지기 전에 먼저 보이는 것들

관리형 쿠버네티스 장애 유형을 보면 공통점이 있다.
대부분 갑자기 터진 것처럼 보이지만,
사실은 그 전에 이미 신호를 보내고 있었다는 점이다.

  • OOMKilled 전에 메모리는 계속 차오른다
  • Evicted 전에 Node 리소스는 이미 임계치에 근접한다
    • a
  • 서비스가 느려지기 전 CPU throttling은 먼저 발생한다

이 글에서는
쿠버네티스 운영에서 “최소한 이것만은 봐야 하는” 모니터링 신호들을
우선순위 중심으로 정리한다.
툴이 아니라 지표와 관점에 집중한다.

모니터링의 목적부터 다시 잡자

쿠버네티스에서 모니터링의 목적은 명확하다.

“장애를 분석하기 위함”이 아니라
“장애를 미리 알아차리기 위함”이다.

그래서 다음 기준이 중요하다.

  • 지금 안 봐도 되는 지표는 무엇인가
  • 지금 반드시 봐야 하는 지표는 무엇인가

모든 걸 다 보려 하면
결국 아무것도 제대로 못 본다.

1순위: Pod 재시작과 종료 사유

가장 먼저 봐야 할 지표는 의외로 단순하다.

  • Pod 재시작 횟수
  • 종료 사유(OOMKilled, Error)

이 두 가지만 꾸준히 봐도
운영 안정성은 눈에 띄게 올라간다.

왜 중요한가

  • Pod는 쿠버네티스에서 가장 작은 단위
  • 대부분의 장애는 Pod 레벨에서 시작된다

“조용히 재시작되고 있는 Pod”는
거의 항상 미래 장애의 전조다.

2순위: 메모리 사용률 (limits 기준)

CPU보다 메모리를 먼저 봐야 한다.

이유는 명확하다

  • CPU 초과 → 느려짐
  • 메모리 초과 → 즉시 종료

특히 다음 상황은 위험 신호다.

  • 평균은 괜찮은데 피크가 limits에 근접
  • 배포 직후 메모리 급증
  • 특정 시간대에만 반복 상승

[이미지: Pod 메모리 사용량이 limits에 접근하는 그래프]

이 패턴을 놓치면
OOMKilled는 거의 예고 없이 터진다.

3순위: CPU throttling 여부

CPU 사용률만 보면 놓치기 쉬운 지표가 있다.

  • CPU throttling

CPU 사용률이 낮아 보여도,
throttling이 걸리면 실제 성능은 급격히 떨어질 수 있다.

이런 신호를 본다

  • 응답 시간 증가
  • 에러는 없는데 “느려짐”
  • 특정 Pod만 반복 발생

[이미지: CPU throttling 발생 시 응답 지연 구조]

이 경우 단순히
“CPU를 더 쓰게 허용”하는 게 해결책일 수 있다.

4순위: Node 리소스 여유도

Pod만 보고 있으면
문제를 절반만 보는 셈이다.

반드시 함께 봐야 할 것은 Node 상태다.

최소한 확인할 것

  • Node 메모리 사용률
  • 디스크 사용량
  • Pod 밀집도

[이미지: Node 리소스 포화로 인한 Pod Evicted 흐름]

Evicted는 Pod 문제가 아니라
Node의 구조적 한계에서 시작되는 경우가 많다.

5순위: HPA 스케일 이벤트

HPA를 쓰고 있다면
“결과”가 아니라 과정을 봐야 한다.

  • 언제 scale-out 됐는가
  • 얼마나 자주 발생하는가
  • scale-in은 제대로 되는가

이런 패턴이 보이면 주의해야 한다.

  • 짧은 시간에 급격한 scale-out 반복
  • 트래픽 감소 후에도 Pod 수 유지
  • 특정 시간대에만 급변

[이미지: HPA 과도한 스케일 이벤트 타임라인]

이는 성능 문제 이전에
비용 문제로 이어질 가능성이 크다.

6순위: 에러율보다 먼저 보는 “지연 시간”

에러율은 중요하지만,
실무에서는 지연 시간(latency) 이 먼저 흔들린다.

  • 평균 응답 시간
  • p95, p99 같은 상위 구간

에러가 안 나도
지연 시간이 늘어나면
사용자는 이미 “장애”로 인식한다.

“에러 없는 장애”는
쿠버네티스에서 가장 흔한 장애 유형이다.

알람은 적게, 하지만 정확하게

모니터링을 망치는 가장 빠른 방법은
알람을 너무 많이 거는 것이다.

현실적인 기준은 다음이다.

  • 새벽에 울리면 반드시 확인할 알람만
  • 원인을 바로 추적할 수 있는 알람만
  • “정보용 알람”은 대시보드로

최소 알람 세트 예시

  • Pod OOMKilled 발생
  • Pod 재시작 횟수 급증
  • Node 메모리/디스크 임계치 접근
  • HPA 비정상 스케일

이 정도만 있어도
대부분의 운영 장애는 조기에 감지된다.

모니터링이 잘 되고 있다는 신호

운영이 안정되기 시작하면
이런 변화가 보인다.

  • 장애를 “사용자보다 먼저” 안다
  • 원인 파악 시간이 짧아진다
  • 트러블슈팅이 감이 아니라 근거 기반이 된다
  • “왜 이런 일이 생겼지?”라는 질문이 줄어든다

정리하며

이번 글에서는
쿠버네티스 운영에서 반드시 봐야 할 모니터링 신호들을
우선순위 중심으로 정리했다.

  • Pod 재시작과 종료 사유
  • 메모리 limits 접근 여부
  • CPU throttling
  • Node 리소스 상태
  • HPA 스케일 이벤트
  • 응답 지연 시간

이 모든 걸 한 번에 완벽하게 볼 필요는 없다.
다만, 어디를 먼저 봐야 하는지 알고 있느냐는
운영 안정성에서 큰 차이를 만든다.

다음 글로는

  • 비용 최적화하다가 실제로 터진 장애 사례
  • “이 지표를 봤으면 막을 수 있었던” 케이스 분석
    같은 실전 사례 중심 글로 이어가면 흐름이 좋다.