복습한 내용과 미션2를 함께 포함해서 작성하였다.

강의 수강 일자 : 25.06.02 (월)
블로그 복습 일자 : 25.06.04 (수)

전 시간에 Object에 대해 배우면서, 쿠버네티스의 Object들이 어떻게 연결되고 생성되는지 봤다면,

이번 시간에는 Object 중 Pod를 생성하고 관리해주는 Probe에 대해 자세히 복습해보겠다.

우선 Deployment 를 선언할 때 template: 코드 아래는 Pod에 대한 내용이라는 건 배웠었다.

Pod 관련 코드들을 살펴보면 다음과 같은 코드를 확인할 수 있다.

startupProbe

Pod에서 기동되는 App은 http 8080 port로 값을 받는다.

App이 기동이 되면 5초 간격으로(periodSeconds) "/startup" api 호출을 하고, 36번까지 api 호출이 실패하게 되면
(failureThreshold) App이 재기동 된다.

App 초기화가 끝났는지 확인하는 동작 과정이며, 초기화가 완료되면 곧바로 liveness와 readiness를 호출해

User 초기화와 외부 API 접근 여부를 확인한다.

livenessProbe

App 기동이 완료되면 readiness와 livenessProbe는 동시에 각자의 api호출을 하게 된다. App 초기화가 되었다고 해서

곧바로 App을 사용할 수는 없고, User 초기화를 해야할 요소들이 있어 해당 과정이 완료되면 App이 살아있게 된다.

livenessProbe는 10초 간격으로 "/liveness" api 호출을 하며, 3번 호출이 실패되면 App이 어떤 오류로 죽었다는 의미이다. 하지만 대부분 startupProbe 호출을 받게 되면 App 초기화가 끝나면서 곧바로 livenessProbe도 호출을 받는다.

어떤 오류로 App 장애가 생겨 livenessProbe가 끊기게 되면 App 재기동을 한다.

readinessProbe

readinessProbe는 App에서 외부 Api를 받을 수 있는 상태인지 확인하는 api호출로, App이 정상적으로 기동을 하고, API를 받게되면 readinessProbe도 호출이 완료되며, App 동작이 모두 정상적으로 실행된다는 의미가 된다.

응용 과제 [미션 2]

원래 HPA에서 minReplica 값을 2로 하여 파드가 최소 2개씩 유지되었지만, 미션에서는 1로 변경하였다.

// HPA minReplica 1로 바꾸기 - Master Node
kubectl patch -n anotherclass-123 hpa api-tester-1231-default -p '{"spec":{"minReplicas":1}}'

쿠버네티스 대시보드와 Loki를 활용해 프로브 값이 바뀜에 따라 어떻게 보여지는지 확인했다.

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

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

기존 startupProbe 상태는 다음과 같았다.

5초 간격으로 App 초기화 여부를 확인하는 상태로, 36번까지 확인해도 초기화가 되지 않는다면 다시 재기동하는 코드지만,

실패 횟수를 줄여 App이 초기화 되기도 전에 재기동 시키면 될 것 같다.

처음에는 36번에서 ->10번으로 줄여봤다.

정상적으로 App이 기동되는 모습을 보였고, 횟수를 5로 줄여봤다.

App이 계속해서 무한으로 재기동되는 모습을 볼 수 있다.

▶ 응용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

부하 증가로 livenessProve와 readinessProve가 동시에 꺼지게 되는 상황이고,

30초 후에 readinessProve failure 카운트 수를 초과시켜 외부 API 트래픽을 받을 수 없게,

3분 후에는 livenessProve failure 카운트 수를 초과시켜 App을 재기동하게 만들어야 한다.

readinessProbe는 10초 간격으로 3번, livenessProbe는 30초 간격 6번으로 설정했다.

부하를 증가 시킨 후, 시간이 지난 후에 api 호출을 한 결과 호출을 실패하는 모습이다.

지속적으로 livenessProbe가 실패를 출력하다, App을 재기동시킨 모습이다.

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

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

Exec로 확인을 했을 때 yaml 파일이 존재

command 명령에 실패(해당 파일이 없을 때)하면 아래와 같이 event로 실패 로그를 볼 수 있어요

라고 하지만 파일이 존재해서 실패 로그는 확인할 수 없었다.