Kubernetes Probe 로 Pod 핼쑥한지 확인하기

프로브는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단이다.

진단을 수행하기 위해서, kubelet은 컨테이너 안에서 코드를 실행하거나, 또는 네트워크 요청을 전송한다.

이러한 진단은 kubelet 이 컨테이너에 의해 구현된 4가지 핸들러 를 호출한다.

 

exec

• 컨테이너 내에서 지정된 명령어를 실행한다.
• 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.

 

grpc

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

 

httpGet

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

 

tcpSocket

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

 

---

restartPolicy 옵션

 

아래 다양한 이유들로 파드는 항상 재시작될 수 있는데 이는 restartPolicy에 의해서 작동한다.

Pod spec 에서 정의할 수 있으며 default 값으로는 Always이고 OnFailure , Never 가 있다.

Always

컨테이너가 어떤 이유로 종료되든 항상 재시작 하여 주로 지속적으로 서비스를 제공해야 하는 웹 서버에 적합하다.

OnFailure

컨테이너가 비정상적인 종료 상태 (즉, 오류로 인해 종료된 경우) 일 때만 재시작된다.

컨테이너가 성공적으로 완료되어 0으로 종료된 경우 재시작하지 않는다.

Never

이 정책을 사용하면, 컨테이너가 어떤 이유로든 종료되었든 절대 재시작되지 않는다.

 

---

Probe Results

 

각 프로브(Probe)는 다음 세 가지 결과 중 하나를 가진다.

 

• Success : 컨테이너가 진단을 통과함.
• Failure : 컨테이너가 진단에 실패함.
• UnKnown : 진단 자체가 실패하였으므로 아무런 액션도 수행되면 안 됨.

 

Kubernetes에서는 컨테이너의 상태를 체크하기 위해 3가지 종류의 프로브를 제공한다.

 

---

 

Readiness Probe

• 이 프로브는 컨테이너가 요청을 처리할 준비가 되었는지 확인한다.
• 준비가 되지 않은 경우, Kubernetes는 해당 컨테이너로 트래픽을 보내지 않는다.

 

언제 사용할까?

• 프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, readiness probe를 지정하길 권장한다.
• 이 경우에서는, readiness probe가 활성 프로브와 유사해 보일 수도 있지만, 스펙에 readiness probe가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서 시작되고 프로브가 성공하기 시작한 이후에만 트래픽을 받는다는 뜻이다.
• 만약 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면, readiness probe를 지정하길 권장한다.
• readiness probe는 liveness probe와는 다르게 준비성에 특정된 엔드포인트를 확인한다.
• 활성 프로브는 애플리케이션 health check에 health가 뜨면 통과하지만, readiness probe는 추가적으로 요구되는 각 백엔드 서비스의 가용이 확보되었는지 확인한다.
• 이를 이용하여, 오류 메시지만 응답하는 파드로 트래픽이 가는 것을 막을 수 있다.
• 만약 failed 애플리케이션과 시동 중에 아직 데이터를 처리하고 있는 애플리케이션을 구분하여 탐지하고 싶다면, readiness probe를 사용하는 것이 더 적합할 것이다.

 

---

 

Liveness Probe

• 이 프로브는 컨테이너가 동작 중인지 확인한다.
• 동작 중이지 않은 경우, Kubernetes는 해당 컨테이너를 재시작한다.

 

언제 사용할까?

• 만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한 상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, liveness probe가 반드시 필요한 것은 아니다.
• 그 경우에는 kubelet이 파드의 restartPolicy에 따라서 올바른 대처를 자동적으로 수행할 것이다.
• 프로브가 실패한 후 컨테이너가 종료되거나 재시작되길 원한다면, liveness probe를 지정하고, restartPolicy를 항상(Always) 또는 실패 시(OnFailure)로 지정한다.

---

Startup Probe

• 이 프로브는 애플리케이션이 시작되었는지 확인하고 Application 이 느리게 시작되는 경우에 유용하다.
• 시작되지 않은 경우, Kubernetes는 해당 컨테이너를 종료하고 재시작한다.

 

언제 사용할까?

• startup probe는 서비스를 시작하는 데 오랜 시간이 걸리는 컨테이너가 있는 파드에 유용하다.
• 긴 활성 간격을 설정하는 대신, 컨테이너가 시작될 때 프로브를 위한 별도의 구성을 설정하여, 활성 간격보다 긴 시간을 허용할 수 있다.
• 컨테이너가 보통 initialDelaySeconds + failureThreshold × periodSeconds 이후에 기동 된다면, startup probe가 liveness probe와 같은 엔드포인트를 확인하도록 지정해야 한다.
• periodSeconds의 기본값은 10s이다.
• 이때 컨테이너가 liveness probe의 기본값 변경 없이 기동 되도록 하려면, failureThreshold를 충분히 높게 설정해주어야 한다.
• 그래야 Deadlocks을 방지하는데 도움이 된다.

---

Summary

 

livenessProbe

컨테이너가 정상인지 체크, 실패 시 재 시작

readinessProbe

컨테이너가 트래픽 받을 준비가 됐는지 체크, 실패 시 트래픽을 받지 않도록 함

startupProbe

컨테이너가 실행되었는지 (Java 프로세스) 체크, 실패 시 재 시작

 

live는 interval을 두고 지속적으로 핼쑥한 지 확인하지만 start 는 컨테이너 시작 시에만 핼쑥한지 확인한다.

---

Example 1. (Define HTTP request)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
  namespace: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
        aws-observability: enabled
    spec:
      containers:
        - name: test
          image: test
          ports:
            - name: http
              containerPort: 8080
          resources:
            limits:
              cpu: 500m
              memory: 512Mi
            requests:
              cpu: 200m
              memory: 256Mi
          livenessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 15
          readinessProbe:
            httpGet:
              path: /
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
          startupProbe:
            httpGet:
              path: /
              port: 8080
            failureThreshold: 30
            periodSeconds: 10

---

Example 2. (Define Command)

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

---

Example 3. (Define TCP)

apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: registry.k8s.io/goproxy:0.1
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10

---

Example 4. (Define gRPC)

apiVersion: v1
kind: Pod
metadata:
  name: etcd-with-grpc
spec:
  containers:
  - name: etcd
    image: registry.k8s.io/etcd:3.5.1-0
    command: [ "/usr/local/bin/etcd", "--data-dir",  "/var/lib/etcd", "--listen-client-urls", "<http://0.0.0.0:2379>", "--advertise-client-urls", "<http://127.0.0.1:2379>", "--log-level", "debug"]
    ports:
    - containerPort: 2379
    livenessProbe:
      grpc:
        port: 2379
      initialDelaySeconds: 10