Pod & Container Failures
비정상적인 Pod·컨테이너 종료를 감지하고, 원인을 찾는 데 필요한 로그, YAML, 타임라인을 남깁니다.
Pod가 5분마다 재시작하는데, kubectl get에는 CrashLoopBackOff만 보입니다
kubernetes.io, Pod Lifecycle, Assign Memory Resources to Containers and Pods; Komodor, 2025 Enterprise Kubernetes Report.
kubectl get pods에는 CrashLoopBackOff만 보이고 원인은 보이지 않습니다. OOMKilled 같은 원인은 kubectl describe에, 실패한 컨테이너의 로그는 kubectl logs --previous에 있습니다.
kubelet은 재시작 사이에 10초, 20초, 40초처럼 대기 시간을 늘리며 최대 5분까지 기다립니다. 누군가 확인할 즈음에는 실패한 컨테이너의 로그가 이미 사라진 경우가 많습니다.
영향이 큰 Kubernetes 장애는 해결까지 중앙값 51분이 걸리고, 39%는 1시간 이상 걸립니다(Komodor, 2025 Enterprise Kubernetes Report).
Back-off: 10초에서 두 배씩, 최대 5분 (kubernetes.io, Pod Lifecycle). 재시작 횟수는 예시입니다.
Wave가 하는 일
컨테이너메모리 limit 초과 또는 크래시- 재시작
kubelet10초, 20초, 40초, 최대 5분 간격으로 재시작 - 상태
kubectl get podsCrashLoopBackOff만 표시, 원인은 없음 - 수동 확인
엔지니어kubectl describe와 logs --previous를 직접 실행
Wave Agent모든 노드에서 cAdvisor와 함께 상태 변화마다 전송- gRPCWave Core11가지 장애 유형 매칭, 폴링 없음
- 장애 시증거이전 로그, pod.yaml, node.yaml을 장애 시점에 저장
- 인시던트Wave Console48시간 히트맵과 인시던트 타임라인
11가지 비정상 전이를 감지합니다
OOMKilled, CrashLoopBackOff, ContainerCrash, 축출, 선점 등을 Wave Agent가 이미 보내는 데이터로 감지합니다. 워크로드마다 켤 필요가 없습니다.
증거를 남깁니다
실패한 순간의 이전 컨테이너 로그, pod.yaml, node.yaml을 저장합니다.
언제 시작됐는지 보여 줍니다
워크로드별 48시간 히트맵과, 무엇이 실패했고 무엇을 확인할지 쉬운 말로 설명하는 장애 타임라인을 제공합니다.