TIL

Liveness, Readiness, Startup Probes

• 공식 문서 - Configure Liveness, Readiness and Startup Probes
• kubelet이 컨테이너 상태를 주기적으로 검사하는 메커니즘
• 세 종류 — liveness(죽었는지), readiness(트래픽 받을 준비 됐는지), startup(아직 초기화 중인지)

Liveness Probe

• 오래 실행되는 앱이 복구 불가능한 고장 상태에 빠졌을 때 감지 → kubelet이 컨테이너를 kill하고 재시작
• 4가지 검사 방식 — exec / HTTP / TCP / gRPC

exec

• 컨테이너 안에서 명령을 실행 — 종료 코드 0이면 성공, 그 외는 실패

livenessProbe:
  exec:
    command: ["cat", "/tmp/healthy"]
  initialDelaySeconds: 5   # 첫 probe까지 대기
  periodSeconds: 5          # 이후 검사 주기

• 동작 예시 — 컨테이너가 시작 후 30초 뒤에 /tmp/healthy를 삭제하면, cat 명령이 실패 → kubelet이 컨테이너를 kill하고 재시작
• failureThreshold(기본 3) 연속 실패해야 컨테이너가 kill됨

HTTP

• kubelet이 컨테이너의 지정 엔드포인트에 HTTP GET 요청 — 응답 코드 200–399면 성공, 그 외는 실패

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 3
  periodSeconds: 3

• 로컬 HTTP 프록시 환경 변수(HTTP_PROXY 등)는 liveness probe에 영향을 주지 않음 (v1.13+)

TCP

• kubelet이 컨테이너의 지정 포트에 TCP 소켓 연결 시도 — 연결 성공이면 healthy, 실패면 unhealthy

livenessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10

• HTTP와 설정 구조가 거의 동일 — 같은 Pod에서 readiness와 liveness를 동시에 TCP로 설정할 수도 있음

gRPC

• 앱이 gRPC Health Checking Protocol을 구현한 경우 사용 (v1.27 stable)

livenessProbe:
  grpc:
    port: 2379
  initialDelaySeconds: 10

• 주의사항
  • Pod IP 또는 hostname으로 실행됨 — gRPC 엔드포인트가 Pod IP에서 listen하도록 설정해야 함
  • 인증 파라미터 미지원 (-tls 등)
  • 모든 에러는 probe 실패로 처리됨 — 별도 에러 코드 구분 없음
  • named port 미지원 (HTTP·TCP는 지원)

Named port

• HTTP·TCP probe에서 port에 숫자 대신 이름으로 참조 가능

ports:
- name: liveness-port
  containerPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port    # 포트 번호 대신 이름

Startup Probe

• 초기화가 오래 걸리는 앱을 보호 — startup probe가 성공할 때까지 liveness·readiness probe를 비활성화
• startup probe가 한 번 성공하면 → 이후부터 liveness probe가 이어받아 deadlock을 빠르게 감지
• startup probe가 끝내 성공하지 못하면 → failureThreshold * periodSeconds 경과 후 컨테이너 kill → restartPolicy에 따라 재시작
• liveness와 같은 검사 방식(exec/HTTP/TCP/gRPC) 사용 가능

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30    # 최대 30번 시도
  periodSeconds: 10        # 10초 간격 → 최대 300초(5분) 대기

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1     # startup 이후엔 빠르게 감지
  periodSeconds: 10

• 위 설정이면 앱은 최대 5분(30 × 10) 동안 초기화 가능. 그 안에 startup probe가 성공하면 liveness가 바로 인계
• startup probe 없이 liveness만 쓰면 — initialDelaySeconds를 길게 잡아야 해서, 초기화 완료 후에도 deadlock 감지가 느려지는 딜레마 발생

Readiness Probe

• 앱이 일시적으로 트래픽을 받을 수 없는 상태를 감지 — 예: 시작 시 대용량 데이터 로딩, 외부 서비스 의존
• readiness probe 실패 → Pod이 Service의 엔드포인트에서 제거됨 (트래픽 차단). 컨테이너를 kill하지는 않음
• 컨테이너 전체 생애주기 동안 계속 실행됨 (시작 시에만 도는 게 아님)
• 설정 구조는 liveness와 동일 — 필드명만 readinessProbe

readinessProbe:
  exec:
    command: ["cat", "/tmp/healthy"]
  initialDelaySeconds: 5
  periodSeconds: 5

liveness와 readiness의 관계

• 두 probe는 서로 독립 — 한쪽의 성공·실패가 다른 쪽에 영향을 주지 않음
• readiness 전에 대기하고 싶으면 initialDelaySeconds나 startupProbe를 사용
• 같은 컨테이너에 둘 다 설정 가능 — readiness로 준비 안 된 Pod에 트래픽 차단 + liveness로 고장 난 컨테이너 재시작. 역할이 다르므로 함께 쓰는 것이 일반적