정의: 두 프로브는 각각 무엇을 확인하나
쿠버네티스에서 컨테이너의 상태를 체크하는 방법으로 Liveness Probe와 Readiness Probe가 있습니다. 이름은 비슷하지만 목적이 완전히 다릅니다.
Liveness Probe는 ‘이 컨테이너가 살아있는가’를 확인합니다. 만약 실패하면 쿠버네티스는 해당 컨테이너를 강제로 재시작합니다. 반면 Readiness Probe는 ‘이 컨테이너가 트래픽을 받을 준비가 되었는가’를 확인합니다. 실패하면 재시작하지 않고, 대신 서비스의 로드밸런싱 대상에서 잠시 제외시킵니다.
동작 원리와 예시로 이해하기
이 둘의 차이를 식당에 비유해볼 수 있습니다. Liveness는 ‘주방장이 쓰러지지 않고 살아있는지’ 확인하는 것이고, Readiness는 ‘지금 당장 새 주문을 받을 수 있는 상태인지’를 확인하는 것입니다. 주방장이 살아있어도(Liveness OK) 재료 준비 중이라 주문을 못 받을 수 있는(Readiness 실패) 상황이 있는 것이죠.
실제 설정 예시는 다음과 같습니다.
livenessProbe: httpGet: path: /healthz port: 8080readinessProbe: httpGet: path: /ready port: 8080
애플리케이션이 시작될 때 DB 커넥션을 맺거나 캐시를 로딩하는 초기화 작업이 있다면, 이 작업이 끝나기 전까지는 Readiness Probe가 실패하도록 만들어서 트래픽이 들어오지 않게 막을 수 있습니다. 반면 프로세스 자체는 정상 동작 중이므로 Liveness Probe는 성공 상태를 유지해 불필요한 재시작을 막습니다.
실무에서 왜 구분해서 써야 하는가
두 프로브를 구분하지 않고 하나로 합쳐서 쓰면 문제가 생깁니다. 예를 들어 DB 커넥션이 일시적으로 끊겼을 때, 이를 Liveness 실패로만 처리하면 애플리케이션이 계속 재시작되면서 오히려 복구가 늦어질 수 있습니다. 이런 경우는 Readiness Probe로 처리해서 ‘잠깐 트래픽만 막고 기다리는’ 방식이 더 안정적입니다.
반대로 프로세스가 데드락에 걸려 응답이 전혀 없는 상황은 Liveness Probe로 감지해서 강제로 재시작해야 정상화됩니다. 이처럼 장애 상황의 성격에 따라 재시작이 필요한지, 아니면 일시적으로 트래픽만 차단하면 되는지를 구분하는 것이 안정적인 서비스 운영의 핵심입니다.
따라서 배포 설정을 작성할 때는 단순히 헬스체크 URL 하나를 복사해서 양쪽에 똑같이 넣기보다, 각 프로브의 목적에 맞는 체크 로직을 따로 구현하는 것이 좋습니다.