liveness, readiness, startup probe란 무엇이며, 각각 언제 사용하는가?

Question

IT Interview Practice · Accepted Answer

Probe는 kubelet이 컨테이너의 건강 상태를 확인하고 그 결과에 따라 행동하게 한다. 세 가지가 있다: **liveness**(살아있는가, 아니면 재시작해야 하는가?), **readiness**(트래픽을 받을 준비가 되었는가?), **startup**(부팅을 마쳤는가?). 각각 다른 질문에 답한다.

## 세 가지 probe 한눈에

```text
LIVENESS   → "앱이 멈췄나/데드락인가?"        FAIL → kubelet이 컨테이너를 RESTART
READINESS  → "지금 트래픽을 처리할 수 있나?"   FAIL → Pod가 Service 엔드포인트에서 제거됨
                                                       (재시작되지 않음)
STARTUP    → "느린 부팅을 마쳤나?"             먼저 실행; 실행되는 동안 liveness &
                                                readiness는 보류됨
```

## Readiness vs liveness — 핵심 구분

```text
Readiness는 트래픽을 통제한다:
  → readiness에 실패한 Pod는 Service load-balancer에서 빠지지만
    계속 실행된다 (예: cache를 예열 중이거나 의존성이 다운됨)
Liveness는 생명을 통제한다:
  → liveness에 실패한 Pod는 죽고 재시작된다 (복구 불가능하게 망가짐)
readiness를 의도했는데 liveness를 쓰면 불필요한 재시작 루프가 생긴다.
```

## Probe 정의

```yaml
spec:
  containers:
    - name: app
      image: myapp:1.0
      ports: [{ containerPort: 8080 }]

startupProbe:            # 느린 시작에게 다른 probe가 개입하기 전 시간을 줌
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30   # 30 * 10s = 시작까지 최대 5분
        periodSeconds: 10

readinessProbe:          # 트래픽 게이트
        httpGet: { path: /ready, port: 8080 }
        initialDelaySeconds: 5
        periodSeconds: 10

livenessProbe:           # 비정상이면 재시작
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
```

## Probe 메커니즘

```text
httpGet    → 경로를 GET; 2xx/3xx = 통과       (웹 앱에 가장 흔함)
tcpSocket  → TCP 연결을 열 수 있나?            (비 HTTP 서비스용)
exec       → 명령을 실행; exit 0 = 통과        (커스텀 체크)
grpc       → 네이티브 gRPC health check
핵심 조절값: initialDelaySeconds, periodSeconds, timeoutSeconds,
           failureThreshold, successThreshold.
```

## startup probe가 존재하는 이유

```text
느리게 시작하는 앱(JVM 예열, 큰 마이그레이션)은 예전에 liveness에 거대한
initialDelaySeconds를 설정하게 만들었고 — 그러면 실제 크래시 감지가 느려졌다.
startupProbe가 이를 해결한다: 느린 부팅을 보호하고, 그것이 통과한 뒤에야
liveness/readiness가 평소의(빡빡한) 타이밍으로 시작된다.
```

```bash
kubectl describe pod app     # 이벤트에서 probe 실패 & 재시작 이유 보기
kubectl get pod app          # READY 열은 readiness를, RESTARTS는 liveness를 반영
```

## 왜 중요한가

Health probe는 Kubernetes가 자가 치유와 안전한 트래픽 라우팅을 제공하는 방식이므로, 세 유형과 각각 언제 쓰는지 이해하는 것은 필수적인 신뢰성 지식이다. 많은 엔지니어를 걸려 넘어지게 하는 결정적 구분은 **readiness**와 **liveness** 사이다: readiness는 **트래픽**을 통제하고(실패한 Pod는 Service load-balancer에서 빠지지만 계속 실행되는데, 예열 중이거나 의존성이 일시적으로 다운되었을 때 이상적), liveness는 **생명**을 통제한다(실패한 Pod는 죽고 재시작되며, 복구 불가능하게 데드락된 경우에 해당). 둘을 혼동하는 것 — readiness를 의도했는데 liveness probe를 쓰는 것 — 은 불필요한 재시작 루프와 장애를 일으키므로, 각 probe가 어떤 질문에 답하는지 아는 것은 직접적으로 실용적이다. **startup** probe는 실제 역사적 고통을 해결한다: 느리게 부팅하는 앱은 한때 liveness에 거대한 `initialDelaySeconds`를 강요했고(이는 진짜 크래시 감지를 지연시켰다), 반면 startup probe는 부팅 구간을 보호하고 startup이 성공한 뒤에야 liveness/readiness가 빡빡한 평소 타이밍으로 실행되게 한다. probe 메커니즘(`httpGet`, `tcpSocket`, `exec`, `grpc`)과 조절값(`initialDelaySeconds`, `periodSeconds`, `failureThreshold` 등)을 이해하면 추측이 아니라 올바르게 health check를 구성할 수 있다. probe는 사용자가 정상 Pod에 도달하는지, 망가진 Pod가 자동으로 복구되는지를 직접 결정하므로, 그것들을 제대로 다루는 것은 Kubernetes에서 신뢰성 있는 프로덕션급 워크로드를 실행하는 데 기초가 된다.

세 가지 probe 한눈에

Readiness vs liveness — 핵심 구분

Probe 정의

Probe 메커니즘

startup probe가 존재하는 이유

왜 중요한가

관련 질문