관리형 쿠버네티스 장애 유형 정리: 클러스터는 정상인데 서비스가 안 될 때

관리형 쿠버네티스에서 자주 겪는 장애 유형들

— “클러스터는 멀쩡한데 서비스가 안 될 때”

관리형 쿠버네티스(EKS, GKE)를 쓰기 시작하면
이런 기대를 하게 된다.

• “이제 클러스터 장애는 신경 안 써도 되겠지”
• “적어도 쿠버네티스 자체가 문제일 일은 없겠지”

절반은 맞고, 절반은 틀리다.
Control Plane 장애는 줄어들지만,
서비스 장애는 여전히 자주 발생한다.
다만 양상이 조금 달라질 뿐이다.

이 글에서는
관리형 쿠버네티스 환경에서 실무적으로 가장 자주 겪는 장애 유형을
원인과 함께 정리한다.

---

관리형 쿠버네티스 장애의 특징

온프레미스나 직접 구축한 쿠버네티스와 비교하면
관리형 환경의 장애는 이런 특징을 가진다.

• Control Plane 문제는 거의 없다
• 대신 워크로드·설정·리소스 문제가 대부분이다
• “클러스터는 정상”인데 서비스만 안 되는 경우가 많다

즉, 장애의 초점이
“플랫폼”에서 “운영 방식”으로 이동한다.

---

1. 가장 흔한 장애: OOMKilled 반복

관리형 쿠버네티스에서도
가장 많이 보는 장애 1위는 여전히 OOMKilled다.

증상

• Pod가 주기적으로 재시작
• 서비스 응답이 간헐적으로 끊김
• 로그에 특별한 에러가 안 보임

kubectl describe pod <pod-name>
Reason: OOMKilled

[이미지: 관리형 쿠버네티스에서 OOMKilled 발생 흐름]

---

왜 관리형에서도 많이 발생할까

• 비용 절감 목적으로 메모리 limits를 타이트하게 설정
• 실제 사용 패턴을 충분히 보지 않고 조정
• JVM, 캐시 기반 서비스 특성 고려 부족

관리형이라고 해서
메모리 문제까지 자동으로 해결해주지는 않는다.

---

2. Node는 살아 있는데 Pod가 Evicted되는 경우

두 번째로 자주 만나는 케이스다.

증상

• Pod 상태가 Evicted
• 특정 Node에서만 반복 발생
• 서비스가 부분적으로 불안정

kubectl describe pod <pod-name>

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

• node had disk pressure
• node was low on memory

[이미지: Node 리소스 압박으로 Pod Evicted]

---

관리형 환경에서의 특징

• Node는 클라우드에서 자동 관리
• 하지만 Node 리소스 사용은 사용자 책임
• 로그, 임시 파일, 이미지 캐시 누적으로 디스크 압박 발생

특히 로그 수집 에이전트나
임시 파일을 많이 쓰는 워크로드에서 자주 나타난다.

---

3. Ingress는 정상인데 외부 접속이 안 되는 문제

관리형 쿠버네티스에서
체감상 가장 헷갈리는 장애 중 하나다.

증상

• Service는 정상
• Pod도 정상
• Ingress 리소스도 존재
• 그런데 외부 접속 불가

[이미지: Ingress 요청이 막히는 지점 예시]

---

원인으로 자주 나오는 것들

• Ingress Controller는 떠 있는데
  실제 로드밸런서 설정 문제
• 보안 그룹 / 방화벽 설정 누락
• Ingress 규칙(host/path) 불일치

관리형 환경에서는
클라우드 네트워크 설정과 쿠버네티스 설정이 함께 얽힌다.

이때 Pod 로그만 계속 봐서는
해결이 안 되는 경우가 많다.

---

4. HPA가 갑자기 과도하게 스케일되는 문제

운영 중 어느 날 갑자기,

• Pod가 평소보다 훨씬 많이 늘어남
• 비용 급증
• 성능은 크게 나아지지 않음

이런 상황도 꽤 자주 발생한다.

[이미지: HPA 과도한 스케일 아웃 예시]

---

원인 패턴

• requests 값이 너무 작게 설정됨
• 순간적인 트래픽 스파이크
• 메트릭 지연 또는 왜곡

관리형 쿠버네티스라고 해서
HPA 판단이 더 똑똑해지는 건 아니다.
설정이 곧 판단 기준이다.

---

5. 배포 후 서비스가 안 살아나는 경우

증상

• Deployment는 업데이트 완료
• Pod는 Running
• 하지만 서비스는 응답 없음

이 경우 로그를 봐도
명확한 에러가 없는 경우가 많다.

---

자주 놓치는 원인

• readiness probe 설정 문제
• ConfigMap / Secret 변경 후 반영 안 됨
• 환경 변수 누락

관리형 환경에서는
배포 자체는 안정적인데,
설정 실수로 인한 장애 비중이 높아진다.

---

6. 클러스터 자체는 정상인데 “느린” 장애

가장 대응하기 어려운 유형이다.

특징

• 에러는 거의 없음
• 응답 시간만 점점 느려짐
• 특정 시간대에만 발생

[이미지: 리소스 부족으로 인한 지연 응답 구조]

---

흔한 원인

• CPU throttling
• Node 리소스 과밀
• 특정 워크로드 쏠림

이런 문제는
단일 Pod 로그만 봐서는 파악이 어렵다.
모니터링 없이는 거의 해결 불가다.

---

관리형 쿠버네티스 장애의 공통점

여기까지의 장애를 묶어보면
공통점이 꽤 분명하다.

• 쿠버네티스 자체 버그는 드물다
• 대부분은 설정·리소스·운영 습관 문제다
• “자동으로 관리해줄 거라 기대한 영역”에서 발생한다

관리형 쿠버네티스는
운영 책임을 줄여주지만, 판단을 대신해주지는 않는다.

---

장애를 줄이기 위한 최소한의 방어선

관리형 환경에서
다음 정도만 지켜도 장애 빈도가 꽤 줄어든다.

• 메모리 limits 보수적으로 설정
• requests 실제 사용량 기준으로 조정
• Ingress/네트워크 변경 시 클라우드 설정 함께 점검
• HPA 이벤트 모니터링
• Evicted, OOMKilled 알람 설정

---

정리하며

이번 글에서는
관리형 쿠버네티스 환경에서 자주 겪는 장애 유형을 정리했다.

• Control Plane 장애는 거의 없다
• 대신 리소스·설정·네트워크 문제가 대부분이다
• “클러스터는 정상인데 서비스만 이상한” 상황이 많다
• 자동화에 대한 과신이 장애로 이어지기 쉽다

관리형 쿠버네티스를 쓴다는 건
“운영을 안 해도 된다”가 아니라,
운영의 초점이 바뀐다는 의미에 가깝다.

다음 글로는
이 장애 유형들과 연결해서,
비용 최적화하다가 실제로 터진 장애 사례들이나
운영 중 반드시 모니터링해야 할 신호들을
정리해보는 것도 좋은 흐름이다.