[쿠버네티스 어나더 클래스 - Sprint1] #5. Application 기능으로 이해하기#1 - Pod(probe)

[참고]

본 글은 인프런의

<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>

강의 내용과 실습을 바탕으로 정리한 기록입니다.

 

 

 

쿠버네티스에서 Probe(프로브)는 컨테이너의 상태를 주기적으로 진단(Health Check)하는 메커니즘입니다. 파드(Pod) 내부의 애플리케이션이 정상적으로 시작되었는지, 사용자 요청을 받을 준비가 되었는지, 혹은 죽지 않고 살아있는지를 쿠버네티스가 스스로 감시하도록 만듭니다.

 

 

쿠버네티스는 크게 3가지 Probe를 제공합니다.

 

Probe 종류	핵심 질문	주요 역할
startupProbe	"앱 초기화가 끝났는가?"	앱이 구동될 때까지 다른 Probe 동작을 유예 (초기 구동 보장)
readinessProbe	"지금 트래픽을 받을 수 있는가?"	준비 미달 시 Service 라우팅에서 제외 (트래픽 차단)
livenessProbe	"앱이 정상적으로 살아있는가?"	응답 불능(Deadlock 등) 시 컨테이너 강제 재기동 (Self-Healing)

 

 

 

deployment.yaml의 컨테이너 스펙 내에 3가지 Probe를 적용한다면 다음과 같습니다.

# deployment.yaml
# spec.template.spec.containers.*
          startupProbe:
            httpGet:
              path: "/startup"
              port: 8080
            periodSeconds: 5
            failureThreshold: 36
          readinessProbe:
            httpGet:
              path: "/readiness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: "/liveness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 3

 

 

 

 

 

어차피 장애 나면 둘 다 실패하는데, Probe를 굳이 구분하는 이유가 뭘까?

 

애플리케이션에 장애가 발생하면 livenessProbe와 readinessProbe 모두 실패(Fail)를 반환합니다. 그렇다면 왜 쿠버네티스는 굳이 이 둘을 나누어 놓았을까요?

그 이유는 "장애 발생 시 쿠버네티스가 취하는 대응 액션"이 완전히 다르기 때문입니다.

 

구분	readinessProbe	livenessProbe
목적	지금 트래픽을 받을 준비가 되었는가?	애플리케이션이 **정상 동작 중(생존)**인가?
실패 시 액션	Service 연결 해제 (트래픽 차단)	Pod 재기동 (Restart)
비유	"손님 받을 준비 안 됐으니 잠시 대기표 끊어!"	"앱이 멈췄으니(Deadlock) 강제 재부팅해!"

 

 

 

 

 

 

Application 동작 중심의 Probe 이해

 

위 다이어그램처럼 애플리케이션 라이프사이클과 연결하면 이해가 훨씬 쉬워집니다.

 

1. startupProbe (App 초기화 단계)

• 상태: DB 연결, Spring 초기화, Heavy한 초기 데이터 로딩 중
• 역할: 앱이 완전히 뜰 때까지 다른 Probe 실행을 유예합니다. 초기화가 느린 앱이 시작도 못 해보고 livenessProbe에 의해 재기동되는 불상사를 막아줍니다.

2. readinessProbe (User 초기화 & 트래픽 제어)

• 상태: 연동 시스템 체크, DB Data Validation 진행 중 또는 순간적인 부하 폭증 상태
• 역할: 실패 시 Service 라우팅 대상에서 해당 Pod를 즉시 제외합니다.
• 핵심: 앱이 완전히 죽은 것은 아니지만, 잠시 트래픽을 처리할 수 없는 상태(지연)일 때 Pod를 강제로 죽이지 않고 트래픽만 유예시켜 안전하게 복구될 시간을 벌어줍니다.

3. livenessProbe (App 기동 완료 후 생존 체크)

• 상태: 애플리케이션이 교착 상태(Deadlock)에 빠졌거나 무한 루프 등으로 응답 불가 상태
• 역할: 연속 실패 시 Pod를 강제로 재기동(Restart)하여 프로세스를 살려냅니다.

 

 

 

 

 

 

응용 과제

🖥️ 응용1 : startupProbe가 실패 되도록 설정해서 Pod가 무한 재기동 상태가 되도록 설정해 보세요.

✅ 과제 풀이

startupProbe 의 API Path를 존재하지 않는 경로로 설정하여 무한 재기동 상태를 유발했습니다.

• failureThreshold : 3
• httpGet.path : /startup_notFound

 

 

🖥️ 응용2 : 일시적 장애 상황(App 내부 부하 증가)가 시작 된 후, 30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요. (아래 API를 날리면 readinessProbe와 livenessProbe가 동시에 실패하게 됩니다)

// 부하 증가 - (App 내부 isAppReady와 isAppLive를 False로 바꿈)
curl http://192.168.56.30:31231/server-load-on

// 외부 API 실패
curl http://192.168.56.30:31231/hello

// 부하 감소 API - (App 내부 isAppReady와 isAppLive를 True로 바꿈)
curl http://192.168.56.30:31231/server-load-off

🖥️ 응용3 : Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요. (꼭 API를 날리는 것만이 readinessProbe 활용의 전부는 아닙니다)