쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2 미션 2

응용 과제

 

응용 1

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

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

 

How?

startupProbe에 failureThreshold 수치를 App이 기동안되도록 낮추면 됩니다.

(Pod가 아닌 Deployment를 수정해 주세요.)

 

startupProbe에 failureThreshold 의미 = startupProbe가 연속으로 몇 번 실패하면 해당 컨테이너를 비정상으로 간주할 것인지?

이 값을 1로 바꾼다면 처음에 App이 기동 중일 때 응답 받을 수 없어 실패 발생 시 컨테이너 비정상으로 간주한다.

그래서 컨테이너를 재기동 하지만 똑같이 1번 실패 후 재기동하여 무한 재기동 상태가 되는 것

 

k8s dashboard에서 Deployment를 아래와 같이 수정하면 됨

startupProbe:
  httpGet:
    path: "/startup"
    port: 8080
  periodSeconds: 5
  failureThreshold: 1
readinessProbe:
  httpGet:
    path: "/readiness"
    port: 8080
  periodSeconds: 10
  failureThreshold: 3
livenessProbe:
  httpGet:
    path: "/liveness"
    port: 8080
  periodSeconds: 10
  failureThreshold: 3

 

결과

 

pod 상태가 CrashLoopBackOff로 pod가 정상적으로 실행되지 못하고 반복적으로 시작과 비정상 종료를 반복하는 상태임을 알 수 있다. 

재시작이 계속 되고 있는 것을 볼 수 있다. 

 

응용 2

일시적 장애 상황(App 내부 부하 증가)가 시작 된 후,

30초 뒤에 트래픽이 중단되고, 3분 뒤에는 App이 재기동 되도록 설정해 보세요.

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

 

How?

livenessProbe에 periodSeconds나 failureThreshold를 늘리면 됩니다.

 

 

30초 뒤에 트래픽이 중단되는 설정은 readinessProbe의 설정을 수정하면 된다. 

(여기서는 이전 설정에도 30초 뒤에 트래픽 중단 되도록 설정해 놔서 수정할 것이 없다.)

readinessProbe의 periodSeconds가 10초이니 10초에 한번씩 체크를 한다. 

그리고 failuerThreshold가 3이니 3번 실패하면 트래픽을 중단하는 것이다. 

따라서 10*3 = 30초 후에 트래픽이 중단된다. 

 

3분 뒤에는 App이 재기동 되도록 설정은 livenessProbe의 설정을 수정하면 된다. 

livenessProbe에 periodSeconds를 늘린다는 것은 livenessProbe = 컨테이너의 생존 여부를 점검하는 헬스 체크를 실행하는 주기를 더 길게 설정하는 것이다. 

이것을 60초로 설정하였으니 60초에 한번씩 생존 여부를 체크한다. 

그리고 failureThreshold를 3으로 했으니 3번 실패하면 재기동하는 것이다. 

따라서 60*3 = 180초 = 3분 후에 재기동하는 것이다. 

 

k8s dashboard에서 Deployment를 아래와 같이 수정하면 됨

startupProbe:
  httpGet:
    path: "/startup"
    port: 8080
  periodSeconds: 5
  failureThreshold: 10
readinessProbe:
  httpGet:
    path: "/readiness"
    port: 8080
  periodSeconds: 10
  failureThreshold: 3
livenessProbe:
  httpGet:
    path: "/liveness"
    port: 8080
  periodSeconds: 60
  failureThreshold: 3

 

그 후 아래 명령어를 통해 테스트 해보면 된다. 

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

 

부하 증가 후 로그 :

isAppReady, isAppLive가 모두 False가 된 것을 볼 수 있다. 

또한 livenessProbe에 periodSeconds를 늘려 readinessProbe와 달리 1분에 한번 체크하는 것을 볼 수 있다.  

 

3분 뒤 재기동 :

21시 6분에 false로 바뀐 후 21시 9분에 재기동하는 로그를 볼 수 있다. 

 

부하 감소 후 로그 : 

isAppReady, isAppLive가 모두 True가 된 것을 볼 수 있다. 

 

응용 3 

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

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

 

How?

readinessProbe에는 exec라는 속성으로 command를 Pod에 날릴 수 있고, 이는 App 기동 시 꼭 필요한 파일 있는지를 체크합니다.

 

k8s dashboard에서 Deployment를 아래와 같이 수정하면 됨

startupProbe:
  httpGet:
    path: "/startup"
    port: 8080
  periodSeconds: 5
  failureThreshold: 10
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

 

Http 명령을 날리는 것이 아니라 exec로 명령어를 pod에 날리는 것이다. 

명령에 실패하면 pod에 event로 실패 로그가 발생한다. 

하지만 아래와 같이 실패 로그는 발생하지 않았다. 

즉 Secret 파일이 존재한다는 의미.

 

출처

https://inf.run/k7mF