當你使用kuberentes的時候，有沒有遇到過Pod在啓動後一會就掛掉然後又重新啓動這樣的惡性循環？你有沒有想過kubernetes是如何檢測pod是否還存活？雖然容器已經啓動，但是kubernetes如何知道容器的進程是否準備好對外提供服務了呢？讓我們通過kuberentes官網的這篇文章Configure Liveness and Readiness Probes，來一探究竟。
本文將向展示如何配置容器的存活和可讀性探針。
Kubelet使用liveness probe（存活探針）來確定何時重啓容器。例如，當應用程序處於運行狀態但無法做進一步操作，liveness探針將捕獲到deadlock，重啓處於該狀態下的容器，使應用程序在存在bug的情況下依然能夠繼續運行下去（誰的程序還沒幾個bug呢）。
Kubelet使用readiness probe（就緒探針）來確定容器是否已經就緒可以接受流量。只有當Pod中的容器都處於就緒狀態時kubelet纔會認定該Pod處於就緒狀態。該信號的作用是控制哪些Pod應該作爲service的後端。如果Pod處於非就緒狀態，那麼它們將會被從service的load balancer中移除。
定義 liveness命令
許多長時間運行的應用程序最終會轉換到broken狀態，除非重新啓動，否則無法恢復。Kubernetes提供了liveness probe來檢測和補救這種情況。
在本次實驗中，你將基於 gcr.io/google_containers/busybox鏡像創建運行一個容器的Pod。以下是Pod的配置文件exec-liveness.yaml：
apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 image: gcr.io/google_containers/busybox livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5
該配置文件給Pod配置了一個容器。periodSeconds 規定kubelet要每隔5秒執行一次liveness probe。 initialDelaySeconds 告訴kubelet在第一次執行probe之前要的等待5秒鐘。探針檢測命令是在容器中執行 cat /tmp/healthy 命令。如果命令執行成功，將返回0，kubelet就會認爲該容器是活着的並且很健康。如果返回非0值，kubelet就會殺掉這個容器並重啓它。
容器啓動時，執行該命令：
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"
在容器生命的最初30秒內有一個 /tmp/healthy 文件，在這30秒內 cat /tmp/healthy命令會返回一個成功的返回碼。30秒後， cat /tmp/healthy 將返回失敗的返回碼。
創建Pod：
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/exec-liveness.yaml
在30秒內，查看Pod的event：
kubectl describe pod liveness-exec
結果顯示沒有失敗的liveness probe：
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 "gcr.io/google_containers/busybox" 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/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的event：
kubectl describe pod liveness-exec
在最下面有一條信息顯示liveness probe失敗，容器被刪掉並重新創建。
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 "gcr.io/google_containers/busybox" 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/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
從輸出結果來RESTARTS值加1了。
NAME READY STATUS RESTARTS AGE liveness-exec 1/1 Running 1 1m
定義一個liveness HTTP請求
我們還可以使用HTTP GET請求作爲liveness probe。下面是一個基於gcr.io/google_containers/liveness鏡像運行了一個容器的Pod的例子http-liveness.yaml：
apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - name: liveness args: - /server image: gcr.io/google_containers/liveness livenessProbe: httpGet: path: /healthz port: 8080 httpHeaders: - name: X-Custom-Header value: Awesome initialDelaySeconds: 3 periodSeconds: 3
該配置文件只定義了一個容器，livenessProbe 指定kubelete需要每隔3秒執行一次liveness probe。initialDelaySeconds 指定kubelet在該執行第一次探測之前需要等待3秒鐘。該探針將向容器中的server的8080端口發送一個HTTP GET請求。如果server的/healthz路徑的handler返回一個成功的返回碼，kubelet就會認定該容器是活着的並且很健康。如果返回失敗的返回碼，kubelet將殺掉該容器並重啓它。
任何大於200小於400的返回碼都會認定是成功的返回碼。其他返回碼都會被認爲是失敗的返回碼。
查看該server的源碼：server.go.
最開始的10秒該容器是活着的， /healthz handler返回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")) } })
容器啓動3秒後，kubelet開始執行健康檢查。第一次健康監測會成功，但是10秒後，健康檢查將失敗，kubelet將殺掉和重啓容器。
創建一個Pod來測試一下HTTP liveness檢測：
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/http-liveness.yaml
After 10 seconds, view Pod events to verify that liveness probes have failed and the Container has been restarted:
10秒後，查看Pod的event，確認liveness probe失敗並重啓了容器。
kubectl describe pod liveness-http
定義TCP liveness探針
第三種liveness probe使用TCP Socket。 使用此配置，kubelet將嘗試在指定端口上打開容器的套接字。 如果可以建立連接，容器被認爲是健康的，如果不能就認爲是失敗的。
如您所見，TCP檢查的配置與HTTP檢查非常相似。 此示例同時使用了readiness和liveness probe。 容器啓動後5秒鐘，kubelet將發送第一個readiness probe。 這將嘗試連接到端口8080上的goproxy容器。如果探測成功，則該pod將被標記爲就緒。Kubelet將每隔10秒鐘執行一次該檢查。
除了readiness probe之外，該配置還包括liveness probe。 容器啓動15秒後，kubelet將運行第一個liveness probe。 就像readiness probe一樣，這將嘗試連接到goproxy容器上的8080端口。如果liveness probe失敗，容器將重新啓動。
使用命名的端口
可以使用命名的ContainerPort作爲HTTP或TCP liveness檢查：
ports: - name: liveness-port containerPort: 8080 hostPort: 8080 livenessProbe: httpGet: path: /healthz port: liveness-port
定義readiness探針
有時，應用程序暫時無法對外部流量提供服務。 例如，應用程序可能需要在啓動期間加載大量數據或配置文件。 在這種情況下，你不想殺死應用程序，但你也不想發送請求。 Kubernetes提供了readiness probe來檢測和減輕這些情況。 Pod中的容器可以報告自己還沒有準備，不能處理Kubernetes服務發送過來的流量。
Readiness probe的配置跟liveness probe很像。唯一的不同是使用 readinessProbe而不是livenessProbe。
readinessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5
Readiness probe的HTTP和TCP的探測器配置跟liveness probe一樣。
Readiness和livenss probe可以並行用於同一容器。 使用兩者可以確保流量無法到達未準備好的容器，並且容器在失敗時重新啓動。
配置Probe
Probe中有很多精確和詳細的配置，通過它們你能準確的控制liveness和readiness檢查：
-
initialDelaySeconds：容器啓動後第一次執行探測是需要等待多少秒。 -
periodSeconds：執行探測的頻率。默認是10秒，最小1秒。 -
timeoutSeconds：探測超時時間。默認1秒，最小1秒。 -
successThreshold：探測失敗後，最少連續探測成功多少次才被認定爲成功。默認是1。對於liveness必須是1。最小值是1。 -
failureThreshold：探測成功後，最少連續探測失敗多少次才被認定爲失敗。默認是3。最小值是1。
HTTP probe中可以給 httpGet設置其他配置項：
-
host：連接的主機名，默認連接到pod的IP。你可能想在http header中設置”Host”而不是使用IP。 -
scheme：連接使用的schema，默認HTTP。 -
path: 訪問的HTTP server的path。 -
httpHeaders：自定義請求的header。HTTP運行重複的header。 -
port：訪問的容器的端口名字或者端口號。端口號必須介於1和65525之間。
對於HTTP探測器，kubelet向指定的路徑和端口發送HTTP請求以執行檢查。 Kubelet將probe發送到容器的IP地址，除非地址被httpGet中的可選host字段覆蓋。 在大多數情況下，你不想設置主機字段。 有一種情況下你可以設置它。 假設容器在127.0.0.1上偵聽，並且Pod的hostNetwork字段爲true。 然後，在httpGet下的host應該設置爲127.0.0.1。 如果你的pod依賴於虛擬主機，這可能是更常見的情況，你不應該是用host，而是應該在httpHeaders中設置Host頭。
本文轉自中文社區-配置Pod的liveness和readiness探針