조건

HPA minReplica 1로 바꾸기

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

• 단일 Pod 환경 조성

HPA와 Deployment의 관계 이해

• HPA 우선순위

  • HPA가 활성화 되면 Deployment의 replicas 설정은 무시

  • HPA가 Pod 개수를 직접 관리하기 때문에 minReplicas 설정이 Pod 개수의 기준이 됨

https://kubernetes.io/ko/docs/tasks/run-application/horizontal-pod-autoscale/

문제 1

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

풀이

startupProbe:
  httpGet:
    path: /startup
    port: 8080
    scheme: HTTP
  timeoutSeconds: 1
  periodSeconds: 5
  successThreshold: 1
  failureThreshold: 1  # 기존 36에서 1로 변경

• Pod가 CrashLoopBackOff 상태에 빠져 무한 재기동

failureThreshold=1

• Java 기반 애플리케이션의 경우 JVM 초기화, 클래스 로딩, 의존성 주입 등 복잡한 초기화 과정 필수

• periodSeconds가 5초로 설정되어 Pod 시작 5초 후 첫 번째 startupProbe 실행

• 대부분의 실제 애플리케이션이 완전히 준비되기에는 부족한 시간

• 애플리케이션이 아직 /startup 엔드포인트에 응답할 수 없는 상태
  

무한 재시작 사이클

• Pod 종료 → Deployment 컨트롤러가 새로운 Pod 생성 → 동일한 설정으로 인한 재실패 → 무한 반복z
  

  백오프 알고리즘 적용

• Kubernetes가 재시작 간격을 점진적으로 증가시킴

• 처음: 즉시 재시작 → 10초 → 20초 → 40초 → 80초 → 최대 5분까지 대기
  

  [root@k8s-master monitoring]# kubectl get pods -n anotherclass-123
  NAME                               READY   STATUS             RESTARTS     AGE
  api-tester-1231-755676484f-znzlj   1/1     Running            0            94m
  api-tester-1231-85dd5c8889-2ktz5   0/1     CrashLoopBackOff   2 (7s ago)   22s

   

   

  ---

  문제 2

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

   

   

  풀이

livenessProbe:
  httpGet:
    path: "/liveness"
    port: 8080
  periodSeconds: 60     # 60초마다 체크
  failureThreshold: 3   # 180초 후 Pod 재시작

readinessProbe:
  httpGet:
    path: "/readiness"
    port: 8080
  periodSeconds: 10     # 10초마다 체크
  failureThreshold: 3   # 30초 후 트래픽 차단

• livenessProbe: 60초 * 3 = 180초 후 Pod 재시작

• readinessProbe: 10초 * 3 = 30초 후 트래픽 차단

부하 시뮬레이션 API

// 부하 증가 API - (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

로그 결과

정상 동작

14:15:17  readinessProbe is Succeed-> isAppReady: true
14:15:17  livenessProbe is Succeed-> isAppLive: true
...
...
14:16:17  readinessProbe is Succeed-> isAppReady: true  
14:16:17  livenessProbe is Succeed-> isAppLive: true

• readinessProbe: 10초 간격으로 정상 체크

• livenessProbe: 동시에 정상 체크

부하 발생 시점

14:16:20  [SyStem] The system load has occurred

• 정확히 server-load-on API가 호출된 시점

• 이 시점부터 내부 플래그들이 False로 변경

Probe 실패

14:16:27  readinessProbe is Failed-> isAppReady: false
14:16:27  livenessProbe is Failed-> isAppLive: false

readinessProbe 3회 실패

14:16:20  부하 발생
14:16:27  첫 번째 [Kubernetes] readinessProbe is Failed-> [System] isAppReady: false
14:16:37  두 번째 [Kubernetes] readinessProbe is Failed-> [System] isAppReady: false
14:16:47  세 번째 [Kubernetes] readinessProbe is Failed-> [System] isAppReady: false

Pod 재시작

14:16:47  마지막 실패 로그
14:17:09  Spring Boot 애플리케이션 재시작 시작
14:17:09  .   ____          _            __ _ _
         /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \

14:17:09  Spring Boot 시작
14:17:54  Tomcat started on port(s): 8080
14:17:58  startupProbe 실패
14:18:17  startupProbe 성공
14:18:47  readinessProbe 성공

확인

curl http://192.168.56.30:31231/hello
Welcome to Kubernetes

문제 3

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

풀이

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

livenessProbe:
  httpGet:
    path: "/liveness"
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

• startupProbe: 애플리케이션 HTTP 서비스 시작 확인

• readinessProbe: 필수 파일 존재 여부로 트래픽 수용 준비 상태 판단

• livenessProbe: 애플리케이션 내부 로직 헬스 체크

Warning   Unhealthy                      
pod/api-tester-1231-564f9446c4-sfczc             

Readiness probe failed: 
cat: /usr/src/myapp/datasource/postgresql-info.yaml: No such file or directory