쿠버네티스 프로브 (활성 프로브, 준비성 프로브)

컨테이너된 App은 스턱(Stuck) 상태에 빠지곤 하는데, 이러한 상황을 감지하고 재시작하여 문제를 해결할 수 있어야한다.

활성 프로브 (liveness probe)

컨테이너가 정상적으로 작동하는지 확인하기 위해 헬스 체크를 컨테이너 스펙에 지정할 수 있다.
App이 HTTP 응답코드에 2xx나 3xx 상태 코드를 반환할 경우 활성 상태로 판단하고 다른 값으로 응답하거나 응답하지 않으면 컨테이너가 죽은 것으로 판단하고 컨테이너를 재시작한다.

livenessProbe:
    httpGet:
        path: /healthz
        port: 8080
    initialDelaySeconds: 3
    periodSeconds: 3

컨테이너가 시작하자 마자 활성 상태를 체크할 경우 어플리케이션은 준비중이기 때문에
응답 코드를 반환하지 못하고 컨테이너가 재시작이 되는 무한 루프가 일어날 수 있다.
initialDelaySeconds를 지정하면 컨테이너가 초기화되고 해당 시간동안 기다렸다가 활성 상태를 체크하기 때문에 위와 같은 문제를 해결할 수 있다.
또한 활성 상태를 계속해서 체크하는것도 셀프 ddos와 같기 때문에 좋은 생각이 아니다. 이러한 경우에는 periodSeconds를 이용하여 활성 상태를 체크하는 주기를 지정 할 수 있다.

준비성 프로브(readiness probe)

어플리케이션의 초기화 과정이 길어나, 하위 프로세스가 완료 될 때까지 기다려야 정상적으로 서비스를 제공할수 있을 때가 있다.
그러한 경우에는 어플리케이션은 쿠버네티스에 일시적으로 요청을 처리할 수 없다는 신호를 보내야 하는데, 이 기능을 준비성 프로브가 제공한다.

readinessProbe:
    httpGet:
        path: /healthz
        port: 8080
    initialDelaySeconds: 3
    periodSeconds: 3

준비성 프로브 검사에 실패한 컨테이너는 재시작이 시작되는 것이 아니라 서비스에서 제거되고, 어플리케이션이 준비 완료 되어 성공 메시지를 전달하게 되면 서비스에 포함되어 정상적으로 작동한다.

(정확히는 쿠버네티스 자체에서는 2xx나 3xx 상태 코드 둘다 준비 완료 상태로 판단하지만 클라우드 로드 밸런서인 ingress에서는 301이 반환될 경우 모든 파드를 비정상으로 판단할 수 있다.)

활성 체크는 http뿐만 아니라 tcpSocket 키워드로 tcp를 이용한 방법이나 gRPC를 이용한 방법, 파일 기반의 준비성 프로브도 제공한다.

minReadySeconds

기본적으로 컨테이너나 파드는 준비성 프로브가 성공하는 순간에 준비가 완료된 것으로 판단한다.
하지만 결함이 발생하여 이를 발견하기까지 특정 시간 이상이 걸린다고 할때, 어플리케이션 업데이트를 하는 경우 이 시간동안 모든 레플리카가 롤아웃될 수 있다.
이를 막기 위해 minReadySeconds(default 0) 옵션을 이용하면 최소 준비 시간 동안은 파드가 준비상태로 판단되지 않는다.