(5) Probe 이해하기

⚓ 쿠버네티스 어나더 클래스 (지상편) - Spring 1, 2 을 듣고 작성하는 복습 블로그 입니다.

 

 

1. Probe 의 기본 개념

 

- Pod 안에 probe 설정하기

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

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

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

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

 

 

 

 

 

 

 

출처URL : https://inf.run/k7mF

 

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

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

 

2. Application 로그를 통한 프로브 동작 분석

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 로그 확인

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

 

3. Application 동작 중심의 프로브 이해

probe 기능이 생긴 이유 

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

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

 

출처URL : https://inf.run/k7mF

Application 동작

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

 

자동화 요구사항

• API 를 받을 수 없는 상태
  • App 상태 체크 (초기화 끝?)
  • 외부 API 접근 🙅‍♀️
• API 를 받을 수 있는 상태 (User 초기화 전)
  • App 상태 체크 (App 이 살아 있는지?)
  • 외부 API 접근 🙅‍♀️
• API 를 받을 수 있는 상태 (User 초기화 후)
  • App 상태 체크 (App 이 살아 있는지?)
  • 외부 API 접근 🙆‍♀️
• App 장애 발생 시
  • 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 연결 해제 (트래픽 받을 수 없음)

 

 

4. 일시적인 장애 상황에서의 프로브 활용

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

• 시스템이 멈출수도 있고
• 시간이 지나다보면 스스로 해결될 수도 있다

livenessProbe 가 실패하면 → Pod 재기동

• probe 가 없었으면 정상으로 돌아왔을 수 있는 상황 → Pod 를 재기동 시키면서 App 에서 처리 중인 작업들은 모두 실패

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

• 실패시 외부 API 접근을 금지시키기 때문에 App 부담 감소 (그대로 두어도 됨)

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

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

 

5. 응용 과제

https://soyeon-devlog.tistory.com/43