피드로 돌아가기
Dev.toInfrastructure
원문 읽기
Liveness Probe 설정 오류로 인한 47분 장애 및 복구 사례
The Spot Instance That Killed Our Payments Service (And Why It Took Us 47 Minutes to Find It)
AI 요약
Context
Redis 의존성을 가진 Payments Service가 Kubernetes 환경에서 운영되는 구조. Redis의 초기 구동 시간과 Liveness Probe의 타임아웃 설정 간의 불일치로 인한 CrashLoopBackOff 발생 가능성 상존.
Technical Solution
- Redis 노드 재시작 시 발생하는 3~4초의 Warm-up 시간 식별
- 기존 2초로 설정된 Liveness Probe Timeout이 Redis 구동 속도보다 짧아 발생하는 Pod 강제 종료 루프 분석
- Probe Timeout을 2초에서 10초로 확장하여 의존성 서비스의 일시적 지연 수용
- InitialDelaySeconds를 15초로 설정하여 초기 구동 시 불필요한 Probe 호출 방지
- 인프라 레벨의 Node Event와 서비스 레벨의 Pod Event 간 타임스탬프 상관관계 분석을 통한 근본 원인 도출
실천 포인트
1. Liveness Probe 설정 시 의존성 서비스의 최대 Warm-up 시간을 반영했는가?
2. 장애 분석 시 로그 확인 전 'kubectl get events'를 통해 클러스터 상태를 먼저 파악하는가?
3. Pod 이벤트뿐만 아니라 'kube-system' 네임스페이스의 Node 이벤트를 함께 모니터링하는가?
4. 가설 설정 전 발생 시점의 타임스탬프를 정밀하게 대조하여 범위를 좁혔는가?