쿠버네티스(Kubernetes) 환경에서 애플리케이션을 운영하다 보면, "Pod(파드)는 실행 중(Running)인데 왜 서비스가 안될까?"와 같은 의문과 마주칠 때가 있습니다. 컨테이너가 시작은 되었지만, 내부 애플리케이션이 요청을 처리할 준비가 되지 않았거나, 일시적인 오류로 인해 멈춰버린 상황일 수 있습니다. 이런 '좀비' 같은 상태의 파드에 계속해서 트래픽이 전달된다면, 결국 사용자 입장에서는 서비스 장애를 겪게 됩니다.
쿠버네티스는 이러한 문제를 해결하고 애플리케이션의 안정성과 신뢰성을 보장하기 위해 강력한 자가 치유(Self-healing) 메커니즘을 제공합니다. 그 핵심에 바로 Liveness, Readiness, Startup 프로브(Probe)가 있습니다.
이 글에서는 이 세 가지 프로브가 각각 어떤 역할을 하며, 왜 우리 애플리케이션에 반드시 구성해야 하는지 상세하게 파헤쳐 보겠습니다.
프로브(Probe)란? 컨테이너의 건강 상태를 확인하는 청진기
프로브는 쿠버네티스의 kubelet(각 노드에서 실행되는 에이전트)이 컨테이너의 상태를 주기적으로 확인하는 진단 메커니즘입니다. 마치 의사가 청진기로 환자의 심장 박동을 확인하는 것처럼, kubelet은 프로브를 통해 컨테이너 내부의 애플리케이션이 정말 '살아서 제 기능을 하는지'를 검사합니다.
검사 방식은 크게 세 가지가 있습니다.
- HTTP GET 요청: 특정 경로(예: /healthz)에 HTTP GET 요청을 보내고, 200번대 응답 코드를 받으면 성공으로 판단합니다. 가장 널리 사용되는 방식입니다.
- TCP 소켓 연결: 지정된 포트로 TCP 연결을 시도하여 성공하면 정상으로 판단합니다. HTTP 서버가 없는 애플리케이션에 유용합니다.
- 명령 실행: 컨테이너 내에서 특정 명령(예: cat /tmp/healthy)을 실행하고, 종료 코드(Exit Code)가 0이면 성공으로 판단합니다.
이러한 검사 결과를 바탕으로 쿠버네티스는 파드를 재시작하거나 서비스에서 제외하는 등 적절한 조치를 취합니다. 이제 각 프로브가 어떤 조치를 이끌어내는지 자세히 알아보겠습니다.
1. Liveness Probe: "살아는 있니?" - 좀비 컨테이너 자동 재시작
Liveness Probe는 컨테이너가 살아있는지(Live)를 확인합니다. 여기서 '살아있다'는 것은 단순히 프로세스가 떠 있는 상태를 넘어, 애플리케이션이 정상적으로 동작하고 응답하는 상태를 의미합니다.
- 언제 필요한가? 애플리케이션에 데드락(Deadlock)이 발생하거나, 내부 로직의 문제로 더 이상 응답하지 않는 상태에 빠졌을 때 Liveness Probe가 진가를 발휘합니다. 이런 상태에서는 컨테이너를 재시작하는 것 외에는 해결 방법이 없는 경우가 많습니다.
- 어떻게 동작하는가? kubelet은 주기적으로 Liveness Probe를 실행하여 컨테이너의 건강 상태를 체크합니다. 만약 프로브가 설정된 횟수(failureThreshold)만큼 연속으로 실패하면, kubelet은 해당 컨테이너가 비정상 상태라고 판단하고 컨테이너를 재시작합니다.
- 주의할 점 Liveness Probe는 재시작을 유발하므로, 애플리케이션이 시작되는 데 시간이 오래 걸리는 경우 성급하게 실패로 판단하지 않도록 initialDelaySeconds와 periodSeconds 값을 신중하게 설정해야 합니다.
# 예시: 30초 후부터 10초마다 /healthz 경로를 확인
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
Liveness Probe를 구성하지 않으면? 애플리케이션이 내부적으로 멈춰도 쿠버네티스는 파드가 'Running' 상태라고만 인지합니다. 따라서 아무런 조치를 취하지 않고, 이 '좀비' 파드는 계속해서 리소스만 차지하며 남아있게 됩니다.
2. Readiness Probe: "일할 준비는 됐니?" - 준비 안 된 컨테이너로의 트래픽 차단
Readiness Probe는 컨테이너가 요청을 처리할 준비가 되었는지(Ready)를 확인합니다. 컨테이너가 시작되었더라도, 무거운 설정 파일을 읽어오거나, 데이터베이스 연결을 초기화하는 등 서비스 제공에 시간이 걸릴 수 있습니다.
- 언제 필요한가? 애플리케이션이 시작 직후 바로 트래픽을 받을 수 없는 경우, 또는 일시적으로 과부하가 걸려 새로운 요청을 받을 수 없는 상태일 때 필요합니다.
- 어떻게 동작하는가? Readiness Probe가 성공하기 전까지, 쿠버네티스는 해당 파드를 서비스(Service)의 엔드포인트(Endpoint) 목록에서 제외합니다. 즉, 프로브가 성공할 때까지 로드밸런서가 해당 파드로 트래픽을 보내지 않습니다. 프로브가 성공하면 파드는 다시 엔드포인트 목록에 추가되어 트래픽을 받기 시작합니다. Liveness Probe와 달리, Readiness Probe가 실패해도 컨테이너를 재시작하지는 않습니다.
- 활용 사례
- 무중단 배포: 새로운 버전의 파드를 배포할 때, Readiness Probe가 성공하기 전까지는 구버전의 파드가 트래픽을 계속 처리하므로 사용자들은 중단 없이 서비스를 이용할 수 있습니다.
- 일시적 과부하 처리: 트래픽이 몰려 애플리케이션이 잠시 요청을 처리하기 어려운 경우, 스스로를 'Not Ready' 상태로 만들어 과부하에서 회복할 시간을 벌 수 있습니다.
# 예시: 5초 후부터 5초마다 readiness-check.sh 스크립트 실행
readinessProbe:
exec:
command:
- cat
- /tmp/ready
initialDelaySeconds: 5
periodSeconds: 5
Readiness Probe를 구성하지 않으면? 쿠버네티스는 파드가 생성되는 즉시 서비스 엔드포인트에 추가하고 트래픽을 보냅니다. 만약 애플리케이션이 아직 준비되지 않았다면, 사용자들은 500 에러와 같은 오류 페이지만 보게 될 것입니다.
3. Startup Probe: "시작하는 데 오래 걸리니?" - 느린 시작을 위한 인내심
Startup Probe는 컨테이너 내의 애플리케이션이 성공적으로 시작되었는지를 확인합니다. 이는 특히 시작하는 데 시간이 오래 걸리는 레거시 애플리케이션이나 무거운 자바 애플리케이션에 유용합니다.
- 언제 필요한가? 애플리케이션이 시작하는 데 수 분이 걸릴 수 있다면, Liveness Probe가 성급하게 실패로 판단하고 컨테이너를 무한 재시작 루프에 빠뜨릴 수 있습니다. initialDelaySeconds를 매우 길게 설정하는 방법도 있지만, 이는 진짜 장애 상황을 감지하는 시간까지 늦추는 단점이 있습니다.
- 어떻게 동작하는가? Startup Probe가 구성되면, 이 프로브가 성공하기 전까지는 Liveness와 Readiness Probe가 비활성화됩니다. kubelet은 Startup Probe가 성공할 때까지 기다립니다.
- Startup Probe 성공 시: kubelet은 Liveness/Readiness Probe를 시작합니다.
- Startup Probe 실패 시: 설정된 횟수(failureThreshold)만큼 실패하면, Liveness Probe가 실패했을 때와 마찬가지로 컨테이너를 재시작합니다.
이는 느리게 시작되는 애플리케이션에 충분한 시작 시간을 부여하면서도, 그 시간 내에 시작하지 못하면 확실하게 재시작시켜주는 안정적인 메커니즘을 제공합니다.
# 예시: 30번 시도(총 5분) 안에 8080 포트가 열리는지 확인
startupProbe:
tcpSocket:
port: 8080
failureThreshold: 30
periodSeconds: 10
Startup Probe를 구성하지 않으면? 느리게 시작되는 애플리케이션의 Liveness Probe initialDelaySeconds를 비정상적으로 길게 설정해야 합니다. 이로 인해 앱 시작 후 발생하는 실제 장애를 감지하는 시간(Time-to-detect)이 길어지는 부작용이 생깁니다.
결론: 안정적인 서비스를 위한 필수 설정
| 프로브 종류 | 목적 | 실패 시 조치 | 주요 사용 사례 |
| Liveness Probe | 컨테이너가 살아있는가? (응답하는가?) | 컨테이너 재시작 | 데드락, 응답 없는 상태 감지 |
| Readiness Probe | 요청을 처리할 준비가 되었는가? | 서비스에서 제외 (트래픽 차단) | 무중단 배포, 초기화, 과부하 방지 |
| Startup Probe | 애플리케이션 시작이 완료되었는가? | 컨테이너 재시작 | 시작이 오래 걸리는 애플리케이션 보호 |
Liveness, Readiness, Startup 프로브는 단순히 있으면 좋은 기능이 아니라, 쿠버네티스 환경에서 예측 가능하고 안정적인 서비스를 구축하기 위한 필수 요소입니다. 각 프로브의 역할을 정확히 이해하고 애플리케이션의 특성에 맞게 적절히 구성함으로써, 우리는 쿠버네티스의 강력한 자가 치유 능력을 100% 활용할 수 있게 될 것입니다. 지금 바로 여러분의 파드 설정에 건강 검진을 위한 청진기를 달아주세요!
'쿠버네티스' 카테고리의 다른 글
| 놓치면 반드시 후회! 쿠버네티스 환경에서 꼭 수집해야 할 로그 총정리 (3) | 2025.07.31 |
|---|---|
| 쿠버네티스 Ingress Controller 대표 주자 3대장: NGINX, Traefik, HAProxy 전격 비교 (5) | 2025.07.31 |
| ☸️ 쿠버네티스와 🏦 Vault를 연동한 시크릿 관리 아키텍처 (5) | 2025.07.30 |
| 🤫 쿠버네티스 시크릿 관리의 정석: Vault와 KMS로 etcd 데이터 안전하게 지키기 (1) | 2025.07.30 |
| 쿠버네티스, Docker Hub 인증 Secret 설정하기 (2) | 2025.07.26 |
