[Kubernetes] health check - livenessProbe / readinessProbe

Pod health check 

	readinessProbe	livenessProbe
정의	컨테이너가 응답할 준비가 되었는지 아닌지/앱이 구동되기 전까지 (파드와)서비스가 연결되지 않도록 해줌	컨테이너가 응답하는지 아닌지
실패 시	파드를 서비스로부터 제외(엔드포인트 제거)	컨테이너 종료 → restart
사용하는 경우	Pod가 처음 구동될 때, 앱이 정상 실행될 때까지 대기해야 하는 경우(=대용량 데이터 불러오는 경우)	앱의 장애상황 감지, 앱이 무한 루프나 Deadlock에 빠져서 응답을 하지 않는 경우
	어떤 노드가 죽어서 거기에 떠있는 파드도 죽었을 때, 다른 노드에 새 파드가 생성되려고 함 → 파드는 Running이지만 앱이 부팅중일 때	파드의 앱이 장애남 → 파드는 돌아감(500에러)

 

readinessProbe : 컨테이너가 실행된 후 서비스 요청 응답 여부 확인, Pod 내 구동되고 있는 프로세스의 health check, 애플리케이션이 시작할 준비가 되었는지 아닌지 확인, 어플리케이션이 구동되기 전까지 서비스와 연결되지 않게 해줌

• 컨테이너가 실행된 다음 바로 서비스에 투입되어 트래픽을 받지 않고, 실제 트래픽을 받을 준비가 되었음을 확인한 후 트래픽을 받을 수 있음 → 애플리케이션 초기화까지 시간이 걸리거나 대용량 데이터를 불러와야하는 상황 등에 대비 가능(→초기화시간에 접속하려고 하면 오류 발생 - 애플리케이션이 로드되지 않은 상황에서 트래픽이 해당 애플리케이션으로 라우팅될 수 있기 때문)
• 컨테이너의 지속적인 유지 및 관리를 위해서 자체적으로 중단을 수행하는 경우
• 실패하면 엔드포인트 컨트롤러는 해당 파드에 연결된 모든 서비스들의 엔드포인트에서 파드의 IP주소 제거(service에서 해당 파드 제외)
• 과정

• Pod가 뜨게되면 readinessProbe는 initialDelaySeconds에 지정한 값 만큼 기다렸다가 periodSeconds의 값만큼 한번씩 httpGet에 세팅한 path와 port로 health check를 위한 HTTP Get 요청을 날린다.

1. 여기서 전달받은 response의 stauts code가 성공(200) 이라면 kubelet은 해당 Pod의 컨테이너가 살아있다고 간주하게 된다.
2. 따라서 Rolling Update시에 새로 뜬 Pod에 대해서 readinessProbe의 역할을 마치기 전까지 기존 Pod를 terminate 시키지 않기 때문에 Rolling Update로 인한 다운 타임이 방지된다.
   1. 하지만 반대로 httpGet에 세팅한 경로로 health check를 했는데 성공(200)이 아닌 400 혹은 500의 status 를 리턴 받는다면, 이 Pod는 이상이 있는 것으로 간주하고 해당 pod로 라우팅되지 않도록 처리한다.

 

livenessProbe : 컨테이너가 실행됐는지 확인, 애플리케이션이 응답하는지 아닌지 확인

• 파드는 Running, 서비스(어플리케이션)는 정상적이지 않은 경우
• 실패하면 컨테이너 종료, restart 정책에 따라 컨테이너 재시작
• EX) 지정된 포트에 TCP 연결을 시도, 연결되지 않으면 컨테이너를 재시작한다.

STATUS가 running일때 READY가 0/X : 아직 컨테이너의 readiness probe가 통과하지 못함

startupProbe : 컨테이너 내의 애플리케이션이 시작되었는지 확인

• 성공할 때 까지 다른 probe는 활성화되지 않음
• 서비스를 시작하는 데 오랜 시간이 걸리거나 불규칙한 컨테이너에 설정하는 경우(써드파티에서 특정 데이터를 다운받는 경우)
• 실패하면 컨테이너 종료, restart 정책에 따라 재시작

컨테이너 진단 handler

컨테이너가 구현한 handler를 kubelet이 호출해 실행

• Exec : 컨테이너 안에 지정된 명령어를 실행하고 종료 코드가 0일 때 Success
  • 볼륨이 연결되어 있는 경우(그 볼륨이 존재하는지 확인)
• TCPSocket : 컨테이너 안에 지정된 IP와 포트로 TCP상태 확인, 포트가 열려있으면 Success
• HTTPGet : 컨테이너 안에 지정된 IP, Port, 경로로 HTTP GET요청 보내 응답 상태 코드가 200~400이면 Success
  • EX) 앱에 /health를 날리면 status:200을 받고 서비스 정상 운영중임을 알려줌

옵션

*() = default

• initialDelaySeconds(0초): 최초 Probe하기 전 delay 설정
• periodSeconds(10초): Probe를 확인하는 시간의 간격
• failureThreshold(3회): 몇 번의 실패 결과를 받아야 정말 실패로 인정할건지
• timeoutSeconds(1초): 지정된 시간까지 결과가 와야함
• successThreshold(1회): 몇 번의 성공 결과를 받아야 정말 성공으로 인정할건지

 

---

실습

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: django
  namespace: ingress-nginx
spec:
  selector:
    matchLabels:
      app: django
  template:
    metadata:
      labels:
        app: django
    spec:
      containers:
      - name: api-server-dev
        image: clnova.kr-central-1.kcr.dev/winnie-repo/swagger_api_server:v5
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8000
	      livenessProbe: # health check
	        tcpSocket:
	          port: 8000
	        initialDelaySeconds: 60 #60초후 tcp통신이 되면 컨테이너 정상적으로 뜸
	        periodSeconds: 30 #30초마다 health check
			failureThreshold: 3 #3번 실패 시 container restart

---
apiVersion: v1
kind: Service
metadata:
  name: django-svc
  namespace: ingress-nginx
spec:
  selector:
    app: django
  ports:
  - port: 8000
    targetPort: 8000
    nodePort: 30300
  type: NodePort

 

• readinessProbe 적용

60초 후 service의 endpoint가 생성됨

Readiness probe가 실패한 django  POD의 상태가 Running 이기는 하지만 Ready 상태가 0/1 →  컨테이너가 준비 상태 아님

• livenessProbe 적용