Kubernetes 健康檢查的兩種機制：Liveness 探測和 Readiness 探測

Kubernetes 健康檢查的兩種機制：Liveness 探測和 Readiness 探測，並實踐了健康檢查在 Scale Up 和 Rolling Update 場景中的應用。
kubelet使用啟動探針來了解何時啟動Container應用程序。如果配置了這樣的探針，它將禁用活動性和就緒性檢查，直到成功為止，以確保這些探針不會干擾應用程序的啟動。這可用於對啟動緩慢的容器進行活動檢查，避免它們在啟動和運行之前被kubelet殺死。

定義活動命令exec

在本練習中，您將創建一個Pod，該Pod可基於k8s.gcr.io/busybox圖像運行一個Container 。這是Pod的配置文件：

pods/probe/exec-liveness.yaml 

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

在配置文件中，您可以看到Pod具有單個Container。該periodSeconds字段指定kubelet應該每5秒執行一次活動性探測。該initialDelaySeconds字段告訴kubelet在執行第一個探測之前應等待5秒。為了執行探測，kubelet cat /tmp/healthy在容器中執行命令。如果命令成功執行，則返回0，並且kubelet認為Container處於活動狀態且健康。如果命令返回非零值，則kubelet將殺死Container並重新啟動它。
在容器壽命的前30秒中，有一個/tmp/healthy文件。因此，在前30秒內，該命令cat /tmp/healthy將返回成功代碼。30秒后，cat /tmp/healthy返回失敗代碼。
在30秒內，查看Pod事件：

FirstSeen    LastSeen    Count   From            SubobjectPath           Type        Reason      Message
--------- --------    -----   ----            -------------           --------    ------      -------
24s       24s     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned liveness-exec to worker0
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulling     pulling image "k8s.gcr.io/busybox"
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulled      Successfully pulled image "k8s.gcr.io/busybox"
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Created     Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
23s       23s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Started     Started container with docker id 86849c15382e

35秒后，再次查看Pod事件：在輸出的底部，有消息指示活動性探針已失敗，並且容器已被殺死並重新創建。

FirstSeen LastSeen    Count   From            SubobjectPath           Type        Reason      Message
--------- --------    -----   ----            -------------           --------    ------      -------
37s       37s     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned liveness-exec to worker0
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulling     pulling image "k8s.gcr.io/busybox"
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Pulled      Successfully pulled image "k8s.gcr.io/busybox"
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Created     Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
36s       36s     1   {kubelet worker0}   spec.containers{liveness}   Normal      Started     Started container with docker id 86849c15382e
2s        2s      1   {kubelet worker0}   spec.containers{liveness}   Warning     Unhealthy   Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory

再等待30秒，並驗證容器已重新啟動：

kubectl get pod liveness-exec
NAME            READY     STATUS    RESTARTS   AGE
liveness-exec   1/1       Running   1          1m

定義活動HTTP請求

另一種活動性探針使用HTTP GET請求。這是基於k8s.gcr.io/liveness 映像運行容器的Pod的配置文件。

pods/probe/http-liveness.yaml 

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: k8s.gcr.io/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

在配置文件中，您可以看到Pod具有單個Container。該periodSeconds字段指定kubelet應該每3秒執行一次活動性探測。該initialDelaySeconds字段告訴kubelet在執行第一個探測之前應等待3秒。為了執行探測，kubelet將HTTP GET請求發送到在Container中運行並在端口8080上偵聽的服務器。如果服務器/healthz路徑的處理程序返回成功代碼，則kubelet認為Container處於活動狀態且運行狀況良好。如果處理程序返回失敗代碼，則kubelet將殺死Container並重新啟動它。

任何大於或等於200且小於400的代碼均表示成功。其他任何代碼均指示失敗。

您可以在server.go中查看服務器的源代碼 。

在Container /healthz處於活動狀態的前10秒鍾中，處理程序返回狀態200。此后，處理程序返回狀態500。

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    duration := time.Now().Sub(started)
    if duration.Seconds() > 10 {
        w.WriteHeader(500)
        w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
    } else {
        w.WriteHeader(200)
        w.Write([]byte("ok"))
    }
})

容器啟動后三秒鍾，kubelet將開始執行運行狀況檢查。因此，前幾次健康檢查將成功。但是10秒鍾后，運行狀況檢查將失敗，並且kubelet將終止並重新啟動Container。

定義TCP liveness探針

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

定義 readiness probes

有時，應用程序暫時無法為流量提供服務。例如，應用程序可能需要在啟動過程中加載大數據或配置文件，或者在啟動后依賴於外部服務。在這種情況下，您不想殺死應用程序，但也不想發送請求。Kubernetes提供了准備就緒探針以檢測和緩解這些情況。帶有容器的容器報告其容器尚未准備就緒，無法通過Kubernetes Services接收流量。
readiness的配置與liveness類似。唯一的區別是您使用readinessProbe字段而不是livenessProbe字段。

readinessProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5

HTTP和TCP就緒性探針的配置也與活動性探針相同。

readiness和liveness可以並行用於同一容器。同時使用這兩者可以確保流量不會到達尚未准備就緒的容器，並且可以確保容器在發生故障時重新啟動。