1️⃣ 개요
StatefulSet을 운영할 때 애플리케이션이 정상적으로 작동하는지 모니터링하는 것이 중요합니다.
특히, Readiness Probe와 Liveness Probe를 올바르게 설정하면 장애 감지 및 복구가 자동으로 이루어질 수 있습니다.
이번 글에서는 StatefulSet의 Readiness & Liveness Probe 개념과, 데이터베이스 및 메시지 브로커에서 Probe를 최적화하는 방법을 설명하겠습니다. 🚀
2️⃣ Readiness Probe vs Liveness Probe 개념 정리
📌 Readiness & Liveness Probe의 차이점
| Probe 유형 | 목적 | 작동 방식 |
| Readiness Probe | 애플리케이션이 트래픽을 받을 준비가 되었는지 확인 | 실패하면 Service에서 Pod 제외 |
| Liveness Probe | 애플리케이션이 정상적으로 실행 중인지 확인 | 실패하면 Pod를 강제 재시작 |
✅ StatefulSet에서는 Readiness Probe가 특히 중요하며, Liveness Probe 설정을 신중하게 해야 합니다.
3️⃣ StatefulSet에서 Readiness Probe 설정 방법
Readiness Probe는 애플리케이션이 정상적으로 시작되고 트래픽을 받을 준비가 되었을 때만 Pod를 Ready 상태로 변경합니다.
📌 MySQL StatefulSet Readiness Probe 예제
readinessProbe:
exec:
command:
- mysqladmin
- ping
- "-h"
- "localhost"
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 3✅ MySQL이 정상적으로 응답할 수 있을 때만 Ready 상태가 됩니다.
📌 Kafka StatefulSet Readiness Probe 예제
readinessProbe:
tcpSocket:
port: 9092
initialDelaySeconds: 15
periodSeconds: 10✅ Kafka 브로커가 포트 9092에서 정상적으로 연결될 때만 Ready 상태가 됩니다.
4️⃣ StatefulSet에서 Liveness Probe 설정 방법
Liveness Probe는 애플리케이션이 죽었거나 응답하지 않는 경우, Pod를 강제 재시작하는 역할을 합니다.
잘못 설정하면 정상적인 Pod도 불필요하게 재시작될 수 있으므로 주의해야 합니다.
📌 PostgreSQL StatefulSet Liveness Probe 예제
livenessProbe:
exec:
command:
- pg_isready
- "-h"
- "localhost"
initialDelaySeconds: 30
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 5✅ PostgreSQL이 pg_isready 응답을 하지 않으면 Pod를 재시작합니다.
📌 Elasticsearch StatefulSet Liveness Probe 예제
livenessProbe:
httpGet:
path: /_cluster/health
port: 9200
initialDelaySeconds: 20
periodSeconds: 15
timeoutSeconds: 5
failureThreshold: 5✅ Elasticsearch 클러스터 상태가 /_cluster/health API에서 응답하지 않으면 Pod를 재시작합니다.
5️⃣ StatefulSet Readiness & Liveness Probe 최적화 전략
✅ 1. 애플리케이션 기동 속도에 따라 initialDelaySeconds 조정
• 데이터베이스 및 메시지 브로커는 시작 시간이 길 수 있으므로 적절한 initialDelaySeconds 값을 설정해야 합니다.
• 일반적인 초기 지연 시간 추천 값:
| 애플리케이션 | 추천 초기 지연 시간 (initialDelaySeconds) |
| MySQL | 10~15초 |
| PostgreSQL | 20~30초 |
| Kafka | 15~20초 |
| Elasticsearch | 20~40초 |
✅ 애플리케이션의 부팅 속도를 고려하여 초기 지연 시간을 조정해야 합니다.
✅ 2. Liveness Probe를 신중하게 설정하여 불필요한 재시작 방지
📌 잘못된 Liveness Probe 설정 사례
livenessProbe:
httpGet:
path: /health
port: 8080
periodSeconds: 5
failureThreshold: 1⛔ 문제점:
• failureThreshold: 1로 설정되어 있어, 일시적인 네트워크 지연만 발생해도 Pod가 즉시 재시작될 가능성이 높음
• 너무 짧은 periodSeconds 값은 불필요한 오버헤드를 초래할 수 있음
📌 개선된 Liveness Probe 설정
livenessProbe:
httpGet:
path: /health
port: 8080
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3✅ 일시적인 장애를 고려하여 failureThreshold 값을 늘리고 periodSeconds 값을 조정해야 합니다.
✅ 3. Readiness Probe를 활용한 Zero Downtime 배포
📌 Rolling Update 중 Readiness Probe를 활용하여 무중단 배포 진행
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
failureThreshold: 3
📌 Rolling Update 실행
kubectl rollout status statefulset myapp✅ Pod가 Ready 상태가 될 때까지 트래픽을 받지 않도록 조정할 수 있습니다.
6️⃣ StatefulSet Readiness & Liveness Probe 테스트 방법
📌 (1) 현재 StatefulSet의 Probe 상태 확인
kubectl describe pod myapp-0
📌 (2) Readiness Probe 테스트 (일부러 실패 유발)
kubectl exec myapp-0 -- mv /health /health.bak
kubectl get pod myapp-0✅ Pod가 Ready 상태에서 제외되는지 확인합니다.
📌 (3) Liveness Probe 테스트 (일부러 실패 유발)
kubectl exec myapp-0 -- kill 1✅ Pod가 자동으로 재시작되는지 확인합니다.
🔥 7️⃣ 결론
✔ Readiness Probe는 트래픽을 받을 준비가 되었는지 확인하는 역할
✔ Liveness Probe는 애플리케이션이 정상적으로 실행 중인지 감지하여 실패 시 Pod를 재시작
✔ 애플리케이션 기동 속도에 따라 initialDelaySeconds 값을 조정해야 함
✔ 잘못된 Liveness Probe 설정은 불필요한 Pod 재시작을 유발할 수 있으므로 신중하게 설정
✔ Readiness Probe를 활용하면 StatefulSet에서 무중단 배포가 가능함