[미션 전 사전 준비]

HPA minReplica 1로 바꿔서 Pod 1개로 진행

[기존] Pod 2개 (HPA 2 -> Deployment 2)

[변경] Pod 1개 (HPA 1 -> Deployment 1)

HPA에 의해서 Pod 1개로 변경

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

(여러분들이 가장 많이 겪게될 Pod 에러입니다)

failureThreshold를 낮춰 빠르게 실패하도록 조정

startupProbe:
  httpGet:
    path: /startup
    port: 8080
    scheme: HTTP
  timeoutSeconds: 1
  periodSeconds: 3   # 더 자주 체크
  successThreshold: 1
  failureThreshold: 3  # 3번만 실패해도 종료

▶ 응용2 : 일시적 장애 상황(App 내부 부하 증가)가 시작 된 후, 30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요.

readinessProbe:
  httpGet:
    path: /health
    port: 8080
  periodSeconds: 5
  failureThreshold: 6       # 5초 간격 * 6번 실패 = **30초 후** 트래픽 중단
  successThreshold: 1
  timeoutSeconds: 1

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  periodSeconds: 10
  failureThreshold: 18      # 10초 간격 * 18번 실패 = **180초 후(Pod 재시작)**
  successThreshold: 1
  timeoutSeconds: 1

[30초 뒤 트래픽 중단]

[3분 뒤 App 재기동]

17시 25분 트래픽 중단

17시 28분 앱 재기동 (3분 뒤)

▶ 응용3 : Secret 파일(/usr/src/myapp/datasource/postgresql-info.yaml)이 존재하는지 체크하는 readinessProbe를 만들어 보세요.

(꼭 API를 날리는 것만이 readinessProbe 활용의 전부는 아닙니다)

readinessProbe:
  exec:
    command:
      - cat
      - /usr/src/myapp/datasource/postgresql-info.yaml
  timeoutSeconds: 1
  periodSeconds: 5
  successThreshold: 1
  failureThreshold: 3

 [체크]

[파일 확인]

 readinessProbe를 HTTP API 방식으로 할지, 아니면 파일 존재(또는 커맨드 실행 결과) 방식 차이

[HTTP 방식]

→ 애플리케이션이 HTTP로 /readiness에 200 OK 응답하면 Ready 상태

API 응답은 서비스 레벨의 준비 상태를 확인

readinessProbe:
  httpGet:
    path: /readiness
    port: 8080

[exec 방식]

→ 파일이 존재하고 열 수 있으면 Ready 상태

파일 체크 등은 환경 구성 요소(Secret, 파일 등) 의 준비 상태 확인

readinessProbe:
  exec:
    command: ["cat", "/usr/src/myapp/datasource/postgresql-info.yaml"]