JVM Pod 재시작 시 초기 요청 실패, StartupProbe로 해결하기

Kubernetes에서 JVM 애플리케이션은 시작이 느리다. Pod가 뜨고 컨테이너가 Running 상태가 되어도, JVM이 준비되기까지는 시간이 더 걸린다. 이 간극을 무시하면 초기 요청이 실패한다.

Karpenter 노드 정리로 Pod가 재스케줄링될 때마다 초기 API 요청이 타임아웃으로 실패하는 문제가 있었다. ReadinessProbe만으로는 부족했다. StartupProbe와 전용 엔드포인트를 도입해서 해결한 과정을 공유한다.

문제 상황

새벽에 Karpenter가 비용 최적화를 위해 유휴 노드를 정리하면서 Pod가 다른 노드로 이동했다. Pod 재시작 자체는 정상이었지만, 재시작 직후 들어온 요청들이 실패했다.

Read full post

Kubernetes Probe 3종류, 왜 나눠져 있는가

Kubernetes Probe 3종류가 항상 헷갈린다. StartupProbe, ReadinessProbe, LivenessProbe. 왜 3개로 나눠져 있고, 언제 어떤 걸 써야 할까?

한눈에 보기

Probe	질문	실패 시
StartupProbe	“앱 시작 끝났어?”	계속 대기 (다른 Probe 차단)
ReadinessProbe	“트래픽 받을 수 있어?”	Service에서 제외 (트래픽 차단)
LivenessProbe	“죽은 거 아니야?”	Pod 재시작

flowchart LR
    subgraph Probes["Probe 역할"]
        Startup[StartupProbe<br/>시작 완료?]
        Readiness[ReadinessProbe<br/>트래픽 OK?]
        Liveness[LivenessProbe<br/>살아있어?]
    end

    subgraph Actions["실패 시 동작"]
        Wait[대기]
        Remove[Service에서 제외]
        Restart[Pod 재시작]
    end

    Startup -->|실패| Wait
    Readiness -->|실패| Remove
    Liveness -->|실패| Restart

    style Startup fill:#74c0fc,color:#000
    style Readiness fill:#69db7c,color:#000
    style Liveness fill:#ef4444,color:#000

쉽게 외우기

StartupProbe   → 시작할 때만 (1회성)
ReadinessProbe → 트래픽 On/Off (반복)
LivenessProbe  → 죽으면 재시작 (반복)

왜 3개로 나눠져 있나

StartupProbe가 없던 시절

JVM 애플리케이션은 시작이 느리다. Spring Boot + DB 연결까지 1~2분 걸리기도 한다.

Read full post