Kubernetes Probe 제대로 쓰기: liveness/readiness/startup 차이와 장애 사례

Kubernetes Probe 제대로 쓰기: liveness/readiness/startup 차이와 장애 사례

목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.

전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.

이 글이 필요한 사람

• 배포/운영 중 5xx/타임아웃/리소스 고갈이 간헐적으로 터지는 팀
• Kubernetes/Nginx/Docker 같은 인프라 설정에서 원인 찾는 시간이 긴 팀
• 장애를 '재현/측정/완화' 순서로 표준화하고 싶은 팀

추천 기본값(실무에서 안전한 시작점)

• 시간 예산(타임아웃)과 종료(드레인)를 먼저 정렬한다
• 운영 설정은 '증상 -> 원인 -> 검증' 루틴으로 바꾼다
• 재시도는 backoff + jitter + 상한이 기본(폭주 방지)

핵심 포인트(요약)

• Kubernetes Probe 제대로 쓰기: liveness/readiness/startup 차이와 장애 사례에서 팀이 합의해야 할 '기준'을 먼저 고정한다
• 실전 예시(헤더/설정/흐름)로 바로 적용 가능하게 만든다
• 운영에서 반복되는 실수를 체크리스트로 막는다

실전 내용(핵심만)

아래는 핵심만 남긴 본문입니다. 여기서 결정한 기준을 팀 문서로 옮기고, 체크리스트로 운영에 반영하는 것이 목표입니다.

팁: 읽다가 애매하면 '참고/출처'의 공식 문서로 규칙을 확인하는 습관을 추천합니다.

목표: 이 글을 읽고 나면 "어떤 선택이 우리 팀에 맞는지"를 기준으로 정할 수 있고, "바로 적용할 체크리스트"를 가져갈 수 있게 만드는 것입니다.

전제: 인기 있는 글은 "개념"보다 "결정"과 "실수 방지"에 시간을 씁니다. 그래서 이 글은 설명을 길게 늘리기보다, 기준/예시/검증 순서로 정리합니다.

이 글이 필요한 사람

• 배포/운영 중 5xx/타임아웃/리소스 고갈이 간헐적으로 터지는 팀
• Kubernetes/Nginx/Docker 같은 인프라 설정에서 원인 찾는 시간이 긴 팀
• 장애를 '재현/측정/완화' 순서로 표준화하고 싶은 팀

추천 기본값(실무에서 안전한 시작점)

• 시간 예산(타임아웃)과 종료(드레인)를 먼저 정렬한다
• 운영 설정은 '증상 -> 원인 -> 검증' 루틴으로 바꾼다
• 재시도는 backoff + jitter + 상한이 기본(폭주 방지)

핵심 포인트(요약)

• Kubernetes Probe 제대로 쓰기: liveness/readiness/startup 차이와 장애 사례에서 팀이 합의해야 할 '기준'을 먼저 고정한다
• 실전 예시(헤더/설정/흐름)로 바로 적용 가능하게 만든다
• 운영에서 반복되는 실수를 체크리스트로 막는다

실전 내용(핵심만)

아래는 핵심만 남긴 본문입니다. 여기서 결정한 기준을 팀 문서로 옮기고, 체크리스트로 운영에 반영하는 것이 목표입니다.

팁: 읽다가 애매하면 '참고/출처'의 공식 문서로 규칙을 확인하는 습관을 추천합니다.

readinessProbe:
  httpGet: { path: /health/ready, port: 8080 }
  periodSeconds: 5
livenessProbe:
  httpGet: { path: /health/live, port: 8080 }
  periodSeconds: 10
startupProbe:
  httpGet: { path: /health/startup, port: 8080 }
  failureThreshold: 60
  periodSeconds: 2

자주 하는 실수(사고로 이어지는 패턴)

• 증상만 보고 설정을 크게 바꿔서(늘리기/끄기) 원인을 숨긴다
• 타임아웃이 레이어마다 달라 장애가 길어지는 상태를 만든다
• 리소스 limit이 너무 낮아 throttling/OOM을 반복한다
• 프로브(readiness/liveness)가 공격적으로 설정돼 재시작 루프를 만든다
• liveness를 공격적으로 잡아 GC/스파이크 때 재시작 루프가 돈다

운영/검증 체크리스트(배포 전에 확인)

• 지표: 오류율/지연(p95/p99)/재시도율을 먼저 확인
• 로그: 업스트림 시간, 상태코드, 종료 이벤트를 남김
• 타임아웃 정렬: client > proxy > server > db 순서로
• 부하/스파이크 테스트로 '터지는 조건'을 재현
• 변경 후 회귀 방지: 알람/대시보드를 같이 추가
• readiness와 liveness의 의미를 섞어 쓰지 않았는가?

FAQ

Q. 설정을 늘리면 왜 일시적으로만 좋아지나요?
A. 대부분 병목이 숨겨졌을 뿐이고, 트래픽이 더 오면 다시 터집니다.

Q. 어디부터 봐야 하나요?
A. 항상 지표(오류율/지연) -> 로그 -> 인프라 순서가 빠릅니다.

Q. 무중단 배포에서 502가 뜨는 이유는?
A. 종료/드레인/타임아웃이 정렬되지 않은 경우가 가장 흔합니다.

바로 실행용 스니펫

# 운영 중 빠르게 상태 확인(예시)
kubectl get pods
kubectl describe pod <pod>
kubectl logs <pod> --since=10m

참고/출처

버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.

• Kubernetes: Configure Probes

왜 이게 어려운가(운영 관점)

운영 이슈는 대부분 '한 설정'이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).

그래서 실무에서는 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.

또한 설정을 늘리는 것(타임아웃/리밋)만으로는 근본 해결이 되는 경우가 드뭅니다. 지표로 확인하고 원인을 분리해야 합니다.

적용 순서(추천)

• 1) 지표로 증상을 고립한다(오류율/지연/재시도율/리소스)
• 2) 타임아웃을 레이어별로 정렬한다(client > proxy > server > db)
• 3) 종료(graceful shutdown)와 readiness 전환을 맞춘다
• 4) 리소스 병목(OOM/throttling)을 분리한다
• 5) 변경은 작게/단계적으로 하고, 롤백/알람을 같이 준비한다

검증/회귀 방지

• 재현: 큰 파일 업/다운로드, 스파이크 트래픽, 롤링 업데이트 중단 테스트
• 로그: upstream_response_time, 종료 이벤트, 재시도 횟수
• 알람: OOMKilled, throttling, 5xx burst, p99 spike

팀 합의 템플릿(복붙용)

# 장애 대응 템플릿(복붙용)
증상: (오류율/지연/시점/영향 범위)
가설: (타임아웃/리소스/종료/프록시/코드)
검증: (재현/로그/지표 링크)
조치: (설정 변경/배포/롤백)
재발 방지: (알람/체크리스트/문서)

자주 하는 실수(사고로 이어지는 패턴)

• 증상만 보고 설정을 크게 바꿔서(늘리기/끄기) 원인을 숨긴다
• 타임아웃이 레이어마다 달라 장애가 길어지는 상태를 만든다
• 리소스 limit이 너무 낮아 throttling/OOM을 반복한다
• 프로브(readiness/liveness)가 공격적으로 설정돼 재시작 루프를 만든다
• liveness를 공격적으로 잡아 GC/스파이크 때 재시작 루프가 돈다

운영/검증 체크리스트(배포 전에 확인)

• 지표: 오류율/지연(p95/p99)/재시도율을 먼저 확인
• 로그: 업스트림 시간, 상태코드, 종료 이벤트를 남김
• 타임아웃 정렬: client > proxy > server > db 순서로
• 부하/스파이크 테스트로 '터지는 조건'을 재현
• 변경 후 회귀 방지: 알람/대시보드를 같이 추가
• readiness와 liveness의 의미를 섞어 쓰지 않았는가?

FAQ

Q. 설정을 늘리면 왜 일시적으로만 좋아지나요?
A. 대부분 병목이 숨겨졌을 뿐이고, 트래픽이 더 오면 다시 터집니다.

Q. 어디부터 봐야 하나요?
A. 항상 지표(오류율/지연) -> 로그 -> 인프라 순서가 빠릅니다.

Q. 무중단 배포에서 502가 뜨는 이유는?
A. 종료/드레인/타임아웃이 정렬되지 않은 경우가 가장 흔합니다.

바로 실행용 스니펫

# 운영 중 빠르게 상태 확인(예시)
kubectl get pods
kubectl describe pod <pod>
kubectl logs <pod> --since=10m

참고/출처

버전/환경에 따라 동작이 달라질 수 있으니, 최종 기준은 공식 문서를 확인합니다.

• Kubernetes: Configure Probes