Readiness Probe 실패로 서비스 투입이 안 될 때 확인해야 할 체크리스트와 해결 방법

Readiness Probe 실패는 컨테이너 프로세스는 정상적으로 실행 중이지만, 실제 사용자 트래픽을 받을 준비가 되지 않아 서비스 엔드포인트에서 제외되는 상태를 의미합니다. 배포 직후 파드(Pod)가 'Running' 상태임에도 불구하고 서비스 접속이 안 되거나, 로드밸런서에서 해당 인스턴스가 계속 'Unhealthy'로 뜬다면 가장 먼저 이 설정을 의심해야 합니다.

많은 운영 환경에서 Liveness Probe와 Readiness Probe를 혼동하여 설정하곤 합니다. Liveness Probe는 문제가 생겼을 때 컨테이너를 '재시작'시키는 것이 목적이지만, Readiness Probe는 준비가 될 때까지 '격리'시키는 것이 목적입니다. 이 차이를 명확히 이해하지 못하면 멀쩡한 컨테이너가 트래픽을 받지 못하고 유휴 상태로 방치되는 상황이 반복됩니다.

주로 애플리케이션의 초기화 시간이 예상보다 길어지거나, 헬스 체크 경로(Health Check Path)에 대한 권한 설정 문제, 혹은 데이터베이스 연결 같은 외부 의존성 해결이 늦어질 때 발생합니다. 특히 트래픽이 몰리는 시점에 오토스케일링으로 생성된 새 파드들이 이 단계에서 막히면 전체 서비스 장애로 이어질 수 있습니다.

이 글에서는 Readiness Probe 실패가 반복될 때 실무자가 즉시 확인해야 할 기술적 포인트와, 설정값 최적화를 통해 배포 안정성을 높이는 구체적인 방법을 정리했습니다.

Readiness Probe 실패 주제를 읽기 전에 먼저 보면 좋은 대표 이미지 · 핵심 포인트: 자주 터지는 원인, 헬스 체크 경로, 배포 직후 점검 순서

핵심 내용 먼저 보기

핵심 키워드 Readiness Probe 실패 · 연관 검색어 Readiness Probe 실패, 쿠버네티스 배포 장애, 헬스 체크 설정, initialDelaySeconds, 쿠버네티스 트러블슈팅

헬스 체크 경로와 응답 코드의 적절성 판단

가장 흔하게 발생하는 실수는 헬스 체크용으로 지정한 경로가 실제 애플리케이션에서 200 OK를 반환하지 않는 경우입니다. 예를 들어, 보안 프레임워크(Spring Security 등)를 적용하면서 /health 같은 경로를 인증 제외 목록에 넣지 않아 401이나 403 에러가 발생하는 사례가 빈번합니다. 쿠버네티스는 200 이상 400 미만의 코드만 성공으로 간주하기 때문에, 인증 실패는 곧 서비스 투입 실패로 이어집니다.

또한, 헬스 체크 로직 내부에 무거운 연산을 넣는 것도 피해야 합니다. 단순히 서버가 살아있는지 확인하는 것을 넘어 매번 DB 커넥션을 새로 맺거나 복잡한 로직을 수행하게 되면, 서버 부하가 높을 때 헬스 체크 응답이 지연되어 멀쩡한 파드가 서비스에서 제외되는 '연쇄 장애'의 원인이 됩니다. 헬스 체크는 최대한 가볍게 유지하되, 핵심 의존성(DB, 캐시)의 연결 상태만 체크하는 수준이 적당합니다.

initialDelaySeconds와 애플리케이션 기동 시간의 불일치

애플리케이션이 구동되어 트래픽을 받을 준비가 되기까지는 물리적인 시간이 필요합니다. 자바 기반의 스프링 부트 애플리케이션처럼 초기 컨텍스트 로딩 시간이 긴 경우, initialDelaySeconds를 너무 짧게 잡으면 Readiness Probe가 너무 일찍 시작되어 실패 횟수(failureThreshold)를 초과해버립니다.

실무에서는 이를 해결하기 위해 무작정 지연 시간을 늘리기보다 Startup Probe를 별도로 사용하는 것이 권장됩니다. Startup Probe가 성공하기 전까지는 Readiness와 Liveness 체크를 유예해주기 때문에, 기동 시간이 들쭉날쭉한 환경에서도 안정적으로 배포를 완료할 수 있습니다. 만약 Startup Probe를 쓰지 않는다면, 평균 기동 시간의 1.5배 정도를 초기 지연 시간으로 설정하고 관찰하는 것이 안전합니다.

리소스 부족으로 인한 타임아웃 발생 여부 확인

컨테이너에 할당된 CPU나 메모리 리소스가 부족하면 애플리케이션의 응답 속도가 급격히 느려집니다. 평소에는 10ms 안에 응답하던 헬스 체크 경로가 배포 직후 리소스 경합으로 인해 timeoutSeconds(기본값 1초)를 넘기게 되면 Readiness Probe 실패로 기록됩니다. kubectl describe pod [파드명] 명령어를 실행했을 때 'Liveness/Readiness probe failed: Get ... context deadline exceeded' 메시지가 보인다면 타임아웃 문제입니다.

이 경우 단순히 타임아웃 시간을 늘리는 것은 임시방편일 뿐입니다. 컨테이너의 CPU Request/Limit 설정을 다시 점검하고, 애플리케이션이 시작될 때 CPU를 과도하게 점유하는 로직이 있는지 확인해야 합니다. 특히 JVM 환경에서는 힙 메모리 설정이 컨테이너 제한값에 근접할 경우 GC(Garbage Collection)가 빈번하게 발생하며 응답 지연을 유발할 수 있습니다.

네트워크 설정 및 서비스 엔드포인트 연결성 점검

애플리케이션 내부 로직에 문제가 없는데도 실패가 반복된다면 네트워크 레이어를 의심해야 합니다. 컨테이너가 리스닝하고 있는 포트와 Readiness Probe에 설정된 port가 일치하는지, 혹은 사이드카 프록시(Istio 등)를 사용하는 경우 프록시가 준비되기 전에 체크가 시도되는 것은 아닌지 확인이 필요합니다.

간혹 로컬 환경에서는 잘 작동하지만 쿠버네티스 내부 DNS 설정이나 네트워크 정책(Network Policy) 때문에 특정 의존성 서비스에 접근하지 못해 Readiness 체크가 실패하는 경우도 있습니다. 파드 내부로 들어가 curl 명령어로 직접 헬스 체크 경로에 접근해 보며, 외부 요인에 의한 차단이 없는지 단계별로 검증하는 과정이 필요합니다.

Readiness Probe 실패는 단순히 설정값의 문제가 아니라 애플리케이션의 생명주기와 인프라 환경이 맞물려 발생하는 복합적인 신호입니다. 실패가 발생했을 때 단순히 수치를 조정하기보다, 왜 준비 상태가 늦어지는지 로그와 이벤트를 통해 근본 원인을 파악하는 것이 중요합니다.

안정적인 운영을 위해서는 배포 전략에 따라 Probe 설정을 세밀하게 튜닝해야 하며, 특히 대규모 트래픽을 처리하는 환경일수록 헬스 체크 로직의 경량화와 타임아웃 관리에 신경 써야 합니다. 이러한 점검 과정은 서비스의 가용성을 높이는 가장 기초적이면서도 강력한 수단이 됩니다.

만약 배포 과정이 아닌, 이미 실행 중인 배치 작업이나 비동기 프로세스에서 발생하는 장애 유형이 궁금하다면 배치 작업 실패 원인 추적: 장애 유형 분류와 로그 분석을 통한 실무 해결 프로세스 글을 통해 더 깊이 있는 분석 방법을 확인해 보시기 바랍니다.

자주 묻는 질문

Readiness Probe가 실패하면 파드가 자동으로 재시작되나요?

아니요. Readiness Probe가 실패하면 해당 파드는 서비스의 엔드포인트 목록에서 제외되어 트래픽만 받지 않게 됩니다. 파드를 재시작시키는 것은 Liveness Probe의 역할입니다.

initialDelaySeconds를 길게 설정하는 것이 항상 좋은가요?

아닙니다. 너무 길게 설정하면 애플리케이션이 이미 준비되었음에도 불구하고 서비스 투입이 늦어져 배포 시간이 불필요하게 길어집니다. Startup Probe를 활용해 기동 완료 시점을 동적으로 감지하는 것이 더 효율적입니다.

헬스 체크 경로에서 404 에러가 발생하면 어떻게 해야 하나요?

애플리케이션 내부에 해당 경로가 실제로 존재하는지, 그리고 컨테이너 설정에 명시된 포트 번호가 애플리케이션이 사용하는 포트와 일치하는지 가장 먼저 확인해야 합니다.

함께 보면 좋은 글

• 배치 작업 실패 원인 추적: 장애 유형 분류와 로그 분석을 통한 실무 해결 프로세스

---

해시태그

#ReadinessProbe실패 #쿠버네티스배포장애 #헬스체크설정 #initialDelaySeconds #쿠버네티스트러블슈팅 #StartupProbe차이