Kubernetes Readiness Probe
1. 정의 (Definition)
Kubernetes Readiness Probe는 컨테이너가 “트래픽을 받을 준비가 되었는지” 확인하는 진단 메커니즘입니다. 이 검사를 통과해야만 해당 파드가 Kubernetes Service의 로드 밸런싱 대상(Endpoints)에 포함됩니다.
2. 등장 배경 (Problem Context)
- 문제: 컨테이너 프로세스(
PID 1)가 시작되었다고 해서 즉시 요청을 처리할 수 있는 것은 아닙니다. 애플리케이션 초기화(설정 로딩, DB 연결, 캐시 워밍업 등)에는 시간이 걸립니다. - 해결: “프로세스 실행 여부”와 “서비스 가능 여부”를 분리했습니다. Readiness Probe가 성공할 때까지는 트래픽을 보내지 않음으로써, 초기화 중인 애플리케이션에 요청이 유입되어 에러가 발생하는 것을 방지합니다.
3. 핵심 메커니즘 (How it Works)
3.1. 동작 방식
kubelet이 주기적으로 컨테이너를 진단합니다.
- Probe 실행: HTTP Get, TCP Socket, Exec 명령 중 하나로 검사합니다.
- 상태 판정:
- Success: Service의 Endpoints에 파드 IP를 추가합니다. (트래픽 유입 시작)
- Failure: Service의 Endpoints에서 파드 IP를 제거합니다. (트래픽 차단, 파드를 재시작하지 않음)
3.2. Liveness Probe와의 차이
| 구분 | Liveness Probe | Readiness Probe |
|---|---|---|
| 목적 | 애플리케이션이 살아있는지 확인 | 애플리케이션이 준비되었는지 확인 |
| 실패 시 동작 | 컨테이너 재시작 (Restart) | 로드 밸런서에서 제외 (Traffic Blocking) |
| 사용 예시 | 데드락, 무한 루프 감지 | 초기화 지연, 일시적 과부하 |
4. 불변 조건과 보장 범위 (Invariants & Guarantees)
- Zero Downtime Deployment: 롤링 업데이트 시, 새 파드가 Readiness Probe를 통과하기 전까지는 기존 파드를 제거하지 않으므로 무중단 배포가 보장됩니다.
- No Traffic until Ready: Probe가 성공하기 전까지는 어떠한 Service 트래픽도 해당 파드로 라우팅되지 않습니다.
5. 비유 (Analogy)
식당의 ‘영업 준비 중’ 팻말과 같습니다.
- 직원은 출근했고 주방 불도 켜졌습니다(Liveness: OK).
- 하지만 재료 손질이 안 끝났다면 손님을 받으면 안 됩니다.
- 문 앞에 ‘영업 준비 중’ 팻말을 걸어두고(Readiness: Fail), 준비가 다 되면 ‘영업 중’으로 바꿉니다(Readiness: Success).
6. 실무적 함의 (Operational Implications)
- 503 오류 방지: 파드가 뜨자마자 트래픽을 받아 500 에러를 뱉는다면,
initialDelaySeconds를 늘리거나 Readiness Probe 조건을 강화해야 합니다. - 일시적 장애 격리: 앱이 일시적으로 과부하 걸려 응답이 느려지면, Readiness Probe가 실패하여 잠시 트래픽을 받지 않게 되고, 그동안 복구할 시간을 벌 수 있습니다.
7. 주의사항 / 오해 (Pitfalls & Misconceptions)
- “Readiness 실패하면 재시작된다?”: 아닙니다. 재시작은 Liveness Probe의 역할입니다. Readiness는 트래픽만 끊습니다.
- “두 Probe 설정이 같아도 된다?”: 위험합니다. Readiness는 민감하게, Liveness는 보수적으로 설정해야 합니다. (잠깐 느리다고 바로 재시작해버리면 무한 재시작 루프에 빠질 수 있습니다.)
8. References
References
- Kubernetes Docs: Configure Liveness, Readiness and Startup Probes
- Related Note: Kubernetes Service