(5) Probe 이해하기

mallin 2025. 6. 2. 11:10

- Pod 안에 probe 설정하기

- startUpProbe, readinessProbe, livenessProbe 총 3개의 Probe 를 설정할 수 있다.

- 각각 성공이랑 실패에 대한 수치도 설정 가능 (success Threshold, failure Threshold)

- 컨테이너 안의 앱에 각 path 에 대한 url 이 사전에 만들어져 있어야 한다.

- 일반적으로 App 기동 시간에 따라 startup Probe 실패수만 조정해서 사용한다.

Pod 가 만들어지자마자 probe 기능들이 동작한다.

App 기동중	startupProbe 를 동작시키면서 10초에 한번씩 /ready API 를 호출 기동중엔 응답을 받을 수 없으니 계속 실패 한 번이라도 응답이 있으면 성공으로 간주 → startupProbe 를 중단시키고, livenessProbe 랑 readlinessProbe 기능을 동작
App 기동 완료	App 이 살아있는 동안은 200 OK 결과 리턴 readinessProbe : 성공을 했을 때 외부 트래픽을 Pod 가 받을 수 있는 상태로 livenessProbe : App 이 살아닜는지 체크
App 장애 발생	API 실패 설정에 따라 두번 실패하면 쿠버네티스는 App 재기동

2-1. 실습 전 사전 준비 작업 (HPA minReplica 를 1로 바꾸기 - Master Node)

kubectl patch -n anotherclass-123 hpa api-tester-1231-default -p '{"spec":{"minReplicas":1}}'

🤔 여기서 HPA 란 ? 부하에 따라 pod 를 늘려주고, 줄여주는 스케일링 역할
기존의 HPA 의 minReplica 는 2로 되어 있었다.
이 수치가 Deployment 에 영향을 준다.
Deployment → replica = 1
- HPA 의 minReplica = 2 이라면 Deployment → replica = 2
- HPA 의 minReplica = 1 이라면 Deployment → replica = 1
Pod 가 두 개면 로그를 볼 때 헷갈릴 수 있기 때문에 하나로 만들기 위해서 사전 작업을 해준다.

2-2. Pod 를 삭제한 다음 Application 로그 확인

App 초기화
startUpProbe 가 5초 간격으로 호출
1. 성공 : readinessProbe, livenessProbe 시작
2. 실패 : 성공할 때까지 반복
3. 동작 확인을 위해 임의로 코드 구성, 실제 App 은 기동되기 전에 API 를 받지 못함
User 초기화 중 초기 데이터 로딩 작업
1. 이 작업이 다 끝나야 App 기동 완료
readinessProbe 는 처음 실패 후 3번이 완료되고, 기동완료가 되서야 성공 (10초 간격 호출)
livenessProbe 는 바로 성공 (10초 간격 호출)

probe 기능이 생긴 이유

쿠버네티스 → Aplication 을 편하게 관리하기 위함

Application 에 동작이 있고, 그 동작으로부터 자동화 되길 바라는 요구 사항이 있다.

Application 동작

App 초기화 (트래픽 받을 준비)
- pod 생성 → Jar 실행 → Spring 초기화 → DB 연결
- 이 과정이 끝나야 App 이 준비되고, 트래픽을 받을 수 있는 준비를 완료
User 초기화 (App 정상 기동)
- App 의 초기 데이터 로딩, 연동 시스템 체크, DB 데이터 Validation
- User 초기화 과정까지 끝나야 App 이 정확하게 기동

자동화 요구사항

Kubernetes 제공 기능

API 를 받을 수 없는 상태
- /startUp API 호출 (성공할 때까지)
- Service 와 Pod 는 미연결
API 를 받을 수 있는 상태 (User 초기화 전)
- /liveness API 호출
- 만약 실패시 Pod 재기동
API 를 받을 수 있는 상태 (User 초기화 후)
- /readiness API 호출
- 만약 성공 시 Service 와 Pod 연결

⇒ redinessProbe, livenessProbe 는 죽을 때까지 호출하기 때문에 호출하는 API 를 가볍게 만들어야 한다.

Probe 동작 정리

startupProbe	"App 초기화가 끝났나?" 🙆‍♀️ (성공) : livenessProbe, readinessProbe 호출 🙅‍♀️ (실패) : 다시 호출
livenessProbe	"App 이 살아있나?" 🙆‍♀️ (성공) : 다시 호출 🙅‍♀️ (실패) : Pod 재기동
readinessProbe	"App 이 트래픽을 받을 수 있나 ?" 🙆‍♀️ (성공) : 다시 호출 (Service, Pod 연결) 🙅‍♀️ (실패) : Service, Pod 연결 해제 (트래픽 받을 수 없음)

앱이 잘 기동되서 서비스 중인 상태 → 🚨 일시적인 장애가 생겼다

livenessProbe 가 실패하면 → Pod 재기동

readinessProbe 가 실패하면 → 외부 트래픽 금지

⇒ livenessProbe 의 체크주기를 readinessProbe 와 같지 않도록 설정

⇒ 실패하는데 걸리는 시간을 길게 설정해서 Pod 가 쉽게 재기동 되는 걸 방지