응용 과제

Application 로그를 통한 probe 동작 분석

#사전 작업

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

• G

  rafana 접속 후 Pod 로그 화면 설정

• Pod 삭제

  
  

• Application Log 확인

  
  

• 마스터 노드에서 실행

  // 1번 API - 외부 API 실패
  curl http://192.168.56.30:31231/hello
  
  // 2번 API 
  // 외부 API 실패
  curl http://192.168.56.30:31231/hello
  
  // 내부 API 성공
  kubectl exec -n anotherclass-123 -it api-tester-1231-7459cd7df-2hdhk -- curl localhost:8080/hello
  kubectl exec -n anotherclass-123 -it <my-pod-name> -- curl localhost:8080/hello
  
  // 3번 API - 외부 API 성공
  curl http://192.168.56.30:31231/hello
  
  // 4번 API
  // 트래픽 중단 - (App 내부 isAppReady를 False로 바꿈)
  curl http://192.168.56.30:31231/traffic-off
  // 외부 API 실패
  curl http://192.168.56.30:31231/hello
  // 트래픽 재개 - (App 내부 isAppReady를 True로 바꿈)
  kubectl exec -n anotherclass-123 -it api-tester-1231-7459cd7df-2hdhk -- curl localhost:8080/traffic-on
  
  // 5번 API - 장애발생 (App 내부 isAppLive를 False로 바꿈)
  curl http://192.168.56.30:31231/server-error

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

[결과]

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

설정 후 API 요청하면 성공하지만 그 이후에는 차단

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

해당 Pod 내부에 파일이 존재하기 때문에 실패 로그는 확인 불가