쿠버네티스 readiness·liveness probe 차이와 설정법
- readiness는 트래픽 수신 여부를 결정합니다.
- liveness 실패는 해당 컨테이너 재시작으로 이어집니다.
- 느린 시작에는 startup probe로 초기화 시간을 확보합니다.
쿠버네티스에서 readinessProbe는 컨테이너가 요청을 받아도 되는지 판단하고, livenessProbe는 컨테이너를 재시작해야 하는 상태인지 판단합니다. 준비가 덜 됐거나 일시적으로 요청을 처리할 수 없으면 readiness 실패로 서비스 트래픽에서 제외하고, 애플리케이션이 교착 상태처럼 스스로 회복하기 어려운 상태라면 liveness 실패로 컨테이너를 재시작하는 식입니다. 두 프로브는 목적이 달라 함께 설정할 수 있습니다.
readiness와 liveness의 핵심 차이
readiness는 트래픽을 받을 준비를 확인합니다
readiness 프로브가 실패해도 쿠버네티스가 컨테이너를 종료하거나 재시작하지는 않습니다. 대신 해당 컨테이너가 준비되지 않았다고 판단해 Pod의 Ready 상태를 낮추고, 매칭되는 Kubernetes Service의 백엔드 대상에서 제외합니다. 프로브가 다시 성공하면 준비 상태가 회복되어 트래픽을 받을 수 있습니다. 예를 들어 기동 직후 설정 파일이나 데이터를 읽는 동안, 또는 필수 연결을 준비하는 동안 요청을 보내지 않도록 할 때 유용합니다.
liveness는 재시작이 필요한 장애를 확인합니다
liveness 프로브가 설정한 횟수만큼 연속 실패하면 kubelet은 해당 컨테이너를 비정상으로 보고 종료한 뒤 Pod의 재시작 정책에 따라 처리합니다. 컨테이너 프로세스가 살아 있지만 교착 상태에 빠져 진행하지 못하는 경우처럼, 재시작이 복구에 도움이 될 때 사용합니다. 프로세스가 이미 종료되면 쿠버네티스가 재시작 정책에 따라 처리하므로 모든 컨테이너에 liveness를 추가해야 하는 것은 아닙니다.
기억할 기준: readiness 실패는 트래픽을 멈추고, liveness 실패는 컨테이너 재시작을 유발합니다. 일시적인 과부하나 의존 서비스 장애를 무조건 liveness 실패로 연결하면 정상 컨테이너까지 반복 재시작될 수 있습니다.
세 가지 프로브를 언제 사용할까
초기화가 오래 걸리면 startup을 둡니다
startupProbe(시작 프로브)는 애플리케이션이 초기화되었는지 확인합니다. 설정하면 startup이 처음 성공할 때까지 readiness와 liveness 검사가 시작되지 않습니다. 시작에 시간이 걸리는 애플리케이션에 liveness를 너무 일찍 적용해 초기화 중 재시작되는 상황을 막을 수 있습니다. startup이 성공한 뒤에는 readiness와 liveness가 각각의 역할을 이어받습니다.
상황별로 실패 동작을 구분합니다
| 프로브 | 확인하는 질문 | 실패 시 동작 | 적합한 상황 |
|---|---|---|---|
| startup | 초기화가 끝났나? | 기준 초과 시 컨테이너 재시작 | 느린 기동, 데이터 로딩 |
| readiness | 지금 요청을 처리할 수 있나? | Pod를 Service 백엔드에서 제외 | 준비 중, 일시적 유지보수 |
| liveness | 재시작으로 회복할 장애인가? | 컨테이너 재시작 | 교착 상태 등 복구 불가 상태 |
세 프로브는 서로를 대신하지 않습니다. readiness가 성공해야 liveness가 실행되는 것도 아닙니다. 애플리케이션의 시작 상태, 요청 처리 가능성, 자체 복구 가능성을 각각 어떤 신호로 판단할지 먼저 정해야 합니다.
프로브 설정을 설계하는 순서
- 검사할 상태를 정의합니다. 단순히 프로세스나 포트가 열렸는지와 실제 요청을 처리할 준비가 됐는지는 다를 수 있습니다. readiness에는 요청 처리를 막아야 하는 상태를, liveness에는 재시작이 필요한 상태를 반영합니다.
- 검사 방식을 고릅니다. HTTP GET, TCP 연결, 컨테이너 내부 명령 실행(exec), gRPC 헬스 체크 가운데 애플리케이션에 맞는 방식을 사용합니다. HTTP는 응답 코드가 200 이상 400 미만이면 성공으로 봅니다. TCP 성공은 포트 연결 가능 여부를 보여줄 뿐, 실제 요청 처리를 보장하지 않습니다.
- 실패 허용 시간과 간격을 맞춥니다.
periodSeconds는 검사 간격,timeoutSeconds는 한 번의 응답 대기 시간,failureThreshold는 실패 허용 횟수입니다. 기본값은 각각 10초, 1초, 3회입니다. 다만 기본값이 서비스의 목표 응답 시간에 맞는 것은 아니므로 실제 기동 시간과 장애 양상을 기준으로 조정합니다. - 기동 허용 시간을 확인합니다. startup 프로브의
failureThreshold × periodSeconds는 대략적인 초기화 허용 시간을 설계할 때 참고할 수 있습니다. 예를 들어 30회, 10초 간격이면 약 300초 범위의 시작 시간을 허용하도록 설계할 수 있습니다. 종료 유예 시간 등으로 실제 종료 시점은 달라질 수 있습니다.
기본 설정 예시
아래 예시는 HTTP 엔드포인트를 사용합니다. /startup, /live, /ready는 애플리케이션에서 각각의 목적에 맞게 구현해야 합니다. 숫자는 예시이므로 서비스 환경에서 응답 지연과 시작 시간을 측정해 조정하세요.
containers:
- name: app
image: example/app:1.0
ports:
- name: http
containerPort: 8080
startupProbe:
httpGet:
path: /startup
port: http
periodSeconds: 10
failureThreshold: 30
livenessProbe:
httpGet:
path: /live
port: http
periodSeconds: 10
timeoutSeconds: 2
failureThreshold: 3
readinessProbe:
httpGet:
path: /ready
port: http
periodSeconds: 5
timeoutSeconds: 2
failureThreshold: 2운영에서 자주 생기는 실수와 점검법
외부 의존 장애를 liveness에 넣는 경우
공유 데이터베이스나 외부 API가 잠깐 느려졌다는 이유로 모든 Pod의 liveness가 실패하도록 만들면, 장애 중인 의존 서비스에 부담을 더 주면서 애플리케이션 컨테이너까지 연쇄 재시작할 수 있습니다. 외부 연결이 없을 때 새 요청을 처리하면 안 되는 상황은 readiness에 반영할 수 있지만, 애플리케이션 자체가 재시작으로 복구될 문제인지 따져 liveness와 분리하세요. readiness 검사를 지나치게 무겁게 만들면 검사 자체가 자원 부족을 키울 수 있습니다.
검사 엔드포인트와 실패 이벤트를 확인합니다
HTTP 헬스 체크는 빠르게 응답하는 전용 경로로 구성하고, 인증이나 무거운 조회 때문에 검사 시간이 늘어나지 않는지 확인합니다. exec 검사는 실행할 때마다 프로세스를 만들기 때문에 Pod 밀도가 높거나 검사 간격이 짧으면 CPU 부담을 고려해야 합니다. 장애가 발생하면 kubectl describe pod의 이벤트와 컨테이너 재시작 횟수, 애플리케이션 로그를 함께 살펴 실패 원인이 잘못된 포트·경로인지, 타임아웃인지, 실제 장애인지 구분합니다.
주의: liveness 검사는 복구 불가능한 애플리케이션 상태를 가려내야 합니다. 너무 짧은 타임아웃이나 낮은 실패 허용 횟수는 부하 상황에서 오탐과 재시작 연쇄를 일으킬 수 있습니다.
필드별 동작과 HTTP·TCP·exec·gRPC 프로브의 세부 제약은 쿠버네티스 공식 프로브 문서에서 확인할 수 있습니다. 설정 예시와 동작 검증 절차는 공식 프로브 구성 가이드를 참고하세요.
자주 묻는 질문
Q. readiness와 liveness를 둘 다 설정해야 하나요?
항상 필수는 아니지만 목적이 다르므로, 요청을 일시적으로 받지 말아야 하는 상태와 재시작이 필요한 상태가 모두 있다면 함께 설정하는 편이 적절합니다. 각 프로브가 확인하는 상태와 실패 동작을 명확히 나누세요.
Q. readiness가 실패하면 Pod가 재시작되나요?
아닙니다. readiness 실패는 컨테이너를 재시작하지 않고 Pod가 준비되지 않은 상태가 되도록 합니다. 해당 Pod는 매칭되는 Kubernetes Service의 트래픽 대상에서 빠지며, 프로브가 성공하면 다시 준비 상태가 될 수 있습니다.
Q. liveness 실패 시 Pod 전체가 다시 만들어지나요?
liveness 실패로 kubelet이 재시작하는 대상은 실패한 컨테이너입니다. 이후 처리는 Pod의 재시작 정책에 따릅니다. 컨테이너 재시작과 Pod 교체는 같은 동작이 아닙니다.
Q. startupProbe와 initialDelaySeconds 중 무엇을 써야 하나요?
기동 시간이 일정하고 짧다면 초기 지연을 둘 수 있습니다. 시작 시간이 길거나 편차가 크고, 기동 완료 후에는 빠르게 장애를 감지하고 싶다면 startupProbe로 시작 허용 시간을 별도로 설계하는 방법이 유용합니다.
Q. readiness와 liveness에 같은 경로를 써도 되나요?
가능하지만 검사 목적이 다르므로 같은 응답이 두 상태를 모두 정확히 나타내는지 확인하세요. readiness에는 트래픽 처리 가능 여부를, liveness에는 재시작이 필요한 내부 장애를 반영하도록 경로를 분리하면 동작을 더 명확하게 관리할 수 있습니다.
