probe에 대해 공부한 내용을 정리한 글입니다.
쿠버네티스 실제로 사용한 적이 없으므로 최대한 하나씩 공부중입니다. 참고해주세요

가능하면 쿠버네티스 공식 홈페이지(https://kubernetes.io/)를 참고하여 진행하였습니다.
또한, 마스터 노드1, 워커노드 2로 실습 진행하였습니다.
🤣🤩😊CKA 자격증 준비 및 쿠버네티스 공부 정리입니다.

이번 포스팅은 쿠버네티스 안내서 subicura를 참고하며 작성합니다.

서론

kubernetes는 컨테이너와 관련된 여러기능을 제공합니다.
컨테이너 생성과 실제 서비스 준비는 약간의 차이가 존재합니다.
서버를 실행시키면 바로 접속할 수 없고, 초기화 시간이 필요하게 되는데, 실제로 접속이 가능할 때 서비스 준비라고 말할 수 있습니다.

예를 들어서, 서버를 실행시키고 db와 연동이 되어야지만 서비스 준비가 되는 것
따라서, kubernetes는 컨테이너 상태 모니터링 기능을 제공합니다.(health check)

쿠버네티스는 컨테이너가 생성되고 서비스가 준비되었다는 것을 체크하는 옵션을 제공하여 초기화하는 동안 서비스되는 것을 막을 수 있습니다

Probe

프로브 는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단(diagnostic)이다. 진단을 수행하기 위해서, kubelet은 컨테이너 안에서 코드를 실행하거나, 또는 네트워크 요청을 전송한다.

Probe의 healthcheck type

• exec
  컨테이너 내에서 커맨드를 실행하고, 실행이 완료되어 상태코드 0을 반환하면 success로 간주한다.

• grcp
  gRPC를 사용하여 원격 프로시저 호출을 수행한다. 체크 대상이 gRPC 헬스 체크를 구현해야 한다. 응답의 status 가 SERVING 이면 진단이 성공했다고 간주한다. gRPC 프로브는 알파 기능이며 GRPCContainerProbe 기능 게이트를 활성화해야 사용할 수 있다.

• httpGet
  지정한 포트 및 경로에서 컨테이너의 IP주소에 대한 HTTP GET 요청을 수행한다. 응답의 상태 코드가 200 이상 400 미만이면 진단이 성공한 것으로 간주한다.

• tcpSocket
  지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행한다. 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다. 원격 시스템(컨테이너)가 연결을 연 이후 즉시 닫는다면, 이 또한 진단이 성공한 것으로 간주한다.

probe의 결과

각 probe는 세 가지 결과 중 하나를 가진다.

• Success
  컨테이너가 진단을 통과함.

• Failure
  컨테이너가 진단에 실패함.

• Unknown
  진단 자체가 실패함(아무런 조치를 수행해서는 안 되며, kubelet이 추가 체크를 수행할 것이다)

probe 종류

kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 종류의 프로브를 수행하고 그에 반응할 수 있다.

kubernetes Probe는 크게 Liveness Probe, Readiness Probe, Startup Probe 세 가지 유형으로 나눌 수 있습니다.

• Liveness Probe : 컨테이너가 활성화되어 올바르게 작동하는지 확인합니다. liveness probe에 실패한다면(지정된 Timeout시간내에 응답을 못하면) 컨테이너를 재시작합니다. 만약, 컨테이너가 libeness probe를 제공하지 않는 경우, 기본 상태는 Success가 된다. 이는 Container 가 제대로 작동하지 않는 상황을 방지하여 신뢰성 확보에 기여합니다.

• Readiness Probe : 컨테이너가 트래픽을 수신할 준비가 되었는지 확인합니다.
  readiness probe에 실패한다면, 드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. 준비성 프로브의 초기 지연 이전의 기본 상태는 Failure입니다. 이는, Container 가 사용 가능한 상태인지를 실시간으로 확인하고, 사용 가능하지 않은 Pod에 대한 요청을 차단합니다.

• startup Probe : 컨테이너 내의 애플리케이션이 시작되었는지를 나타냅니다.
  스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 활성화 되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다. 컨테이너에 스타트업 프로브가 없는 경우, 기본 상태는 Success 이다.

liveness probe와 startup probe는 비슷해보이지만, startup Probe는 어플리케이션이 시작되었는지를 판단하기 때문에 타이밍에 따른 probe인 것 같습니다.

livenessProbe와 startupProbe의 추가 정보

Probe별 사용 시나리오

• Liveness Probe

• • 컨테이너 속 프로세스가 unhealthy 상태가 되어서 프로세스가 중단되면 kubelet이 재시작정책에 따라 자동으로 수행됨.
• • 어플리케이션이 데드락 상태에 머무르는 것을 감지하여 재시작할 때 유용

• Readiness Probe

• • probe가 성공한 경우에만 파드에 트래픽을 전송하려고 한다면 readiness probe를 지정하면 된다. 왜냐하면 애플리케이션이 로드되지 않은 상황에서도 트래픽이 어플리케이션으로 라우팅 될 수 있기 때문
• • 컨테이너의 지속적인 유지 및 관리를 위해서 pod를 죽이는 liveness probe가 아닌 readiness probe를 사용할 수 있음

• Startup Probe

• • 서비스를 시작하는데 오랜 시간이 걸리거나 불규칙적인 컨테이너에 설정

HealthCheck가 도움이 되는 방법

Readiness Probe

앱이 준비되고 시작하는데 1분이 걸린다고 가정합니다.
프로세스가 시작되었더라도 서비스가 가동되어 실행될 때까지는 작동하지 않습니다.
하지만, kubernetes는 컨테이너 내부 프로세스가 시작되자마자 트래픽을 보내기 시작합니다. 따라서 readiness probe를 사용하여 새 복사본으로 트래픽을 보낼 수 있도록 허용하기 전에 앱이 완전 시작될 때까지 기다립니다.

Liveness Probe

앱에 심각한 교착상태가 발생하여 무기한 중단되고 요청처리가 중단되는 시나리오를 상상해보겠습니다. 프로세스가 계속 실행되기 때문에 기본적으로 kubernetes는 모든 것이 정상이라고 생각하고 손상된 Pod를 요청보냅니다. liveness probe를 사용하여 더이상 요청을 처리하지 않는다는 것을 감지하고 pod를 재실행시킵니다.

출처: Google Cloud

LivenessProbe httpGet 방식 사용해보기

http get 요청으로 확인해보겠습니다.
Probe의 위치는 spec.containers아래 속성에 포함됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: echo-lp
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      livenessProbe:
        httpGet: 							# httpGet 요청을 보냄
          path: /not/exist 					# http 서버에서 접근하는 경로
          port: 8080						# 컨테이너에서 접근할 포트
        initialDelaySeconds: 5				# kublet한테 probe를 5초후에 재시작하라고 지시
        timeoutSeconds: 2 # Default 1		# 최소값은 1이고 probe가 시간초과 되는 시간
        periodSeconds: 5 # Defaults 10		# liveness 체크를 5초주기로 설정
        failureThreshold: 1 # Defaults 3	# probe를 실패하면 재시도하기까지의 시간

일부러 존재하지 않는 path(/not/exist)를 입력하였습니다.

처음에는 liveness probe가 적용되지 않아 running 상태였다가 -> CrashLoopBackOff 에러를 뿜으면서 Pod가 계속 재시작되고 있습니다.

ReadinessProbe httpGet 방식 사용해보기

컨테이너가 준비되었는지 체크하고 정상적으로 준비되지 않았다면 Pod으로 들어오는 요청을 제외합니다.

livenessProbe와 차이점은 문제가 있어도 Pod을 재시작하지 않고 요청만 제외한다는 점입니다.

apiVersion: v1
kind: Pod
metadata:
  name: echo-rp
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      readinessProbe:
        httpGet:
          path: /not/exist
          port: 8080
        initialDelaySeconds: 5
        timeoutSeconds: 2 # Default 1
        periodSeconds: 5 # Defaults 10
        failureThreshold: 1 # Defaults 3

Ready상태가 0/1인 것을 확인할 수 있습니다.

Liveness Probe + Readiness Probe

보통 livenessProbe와 readinessProbe를 같이 적용합니다. 상세한 설정은 애플리케이션 환경에 따라 적절하게 조정합니다.

apiVersion: v1
kind: Pod
metadata:
  name: echo-health
  labels:
    app: echo
spec:
  containers:
    - name: app
      image: ghcr.io/subicura/echo:v1
      livenessProbe:
        httpGet:
          path: /
          port: 3000
      readinessProbe:
        httpGet:
          path: /
          port: 3000

3000번 포트와 /경로는 정상적이기 때문에 pod가 오류 없이 생성되었습니다.

Probe를 꼭 사용해야 하나요?

실무에서 사용하는 방식은 잘 모르겠지만, Pod의 상태체크를 진행하면서 socket, httpGet 등 다양한 방식으로 예외처리가 가능하다는 점에서 안 할 이유는 없는 듯 하다.

REFERENCE

블로그 - 노는게 제일 좋아
블로그 - OpenMARU
쿠버네티스 공식문서 - Pod의 라이프 사이클