[Sprint1] Application 기능으로 이해하기 - Probe

우선 Probe를 이해하기 위해 Pod를 재기동 시키면서 로그를 지켜보았다.

 

이 로그들은 강사님께서 임의로 코드를 구성하신 것! 

 

 

 

 

---

 

과제

이번엔 재미있게도 과제가 있었다.

참고

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

Configure Liveness, Readiness and Startup Probes

 

 

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

 

내 생각
1. 애초에 API를 보내는 것부터 문제
- Port를 잘못 설정했다던가? 
2. API에서 200~400 외의 값 반환 or API에서 Probe로 못 보냄 
- 쿠버네티스 공식 문서에서 livenessProbe는 200에서 400 사이의 값을 반환 받아야 성공이라고 함(startup은?)
3. 기타 설정값
- configure 수정해보기

 

1. startupProbe Port 53으로 변경해봄

▲ startupProbe는 성공했다는 얘기 없음

▲ 다른 Probe들이 성공했다는 로그는 뜨지만, 연결되지 않았다는 것을 알 수 있음! 

 

kubectl logs api-tester-1231-6797cdf95c-rvdp4 -n anotherclass-123

▲master node에서 실제로 로그를 확인했다. 앱이 시작하고 startupProbe를 작동시켰지만, API를 보내고 실패했기 때문에 readinessProbe를 기동시키지 못했고, 이 앱은 트래픽을 받을 수 없다. 

 

▲무한 재기동 되고 있는 Pod들 

terminationGracePeriodSeconds를 따로 설정하지 않았으므로, 30초 마다 재기동 된다. 

 

 

2. API에서 200~399 외의 값을 반환했을 때

이건 애블리케이션의 코드에서 결정되는 거라고 하셔서 보류하기로 했다.... 

 

3. configure 수정

GPT 요약

다른 값들은 시간이 지나면 어떻게든 StartupProbe가 성공하는데 반해, failureThreshold를 1로 설정하면 1번 StartupProbe가 실행되고 결국 실패로 간주될 것이라고 생각했다.

 

 

 

 

 

궁금했던 것

1처럼 startupProbe의 Port값을 변경해서 하면 왜 Running 상태이고, failureThreshold를 1로 설정하면 왜 CrashLoopBackOff가 나올까?

 

 

 

 

 

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

(아래 API를 날리면 readinessProbe와 livenessProbe가 동시에 실패하게 됩니다)

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

 

 

내 생각
30초 뒤 트래픽 중단 -> readinessProbe의 설정값 수정
3분 뒤 App 재기동 -> livenessProbe의 설정값 수정

livenessProbe의 terminationGracePeriodSeconds 수정은 종료 시작부터 종료 까지 잘 종료될 수 있게 유예 시간을 주는 것이기 때문에 상관이 없었다! 

Probe의 Configure값 정리

▲ 참고로 Ready 0/1 이런 상황도 ReadinessProbe를 통과하지 못해서 그런 경우가 많다. 

# 기존 Probe
		  readinessProbe:
            httpGet:
              path: "/readiness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: "/liveness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 3
            
# 내가 수정한 Probe
          readinessProbe:
            httpGet:
              path: "/readiness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: "/liveness"
              port: 8080
            periodSeconds: 10
            failureThreshold: 18

▲ 이렇게 수정했다. 

 

 

 

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

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

 

내 생각
path에 /usr/src/myapp/datasource/postgresql-info.yaml를 입력
=> 안됨! 왜? HttpGet은 로컬 파일 경로는 인식하지 못 하기 때문 
그럼 gRPC? TCP?

 

▲ GPT에 의하면 파일이니까 exec를 사용하면 될 것 같음! 

 

 

이제 내가 할 수 있는 게 별로 없어서 강사님의 답을 확인함 

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