如何配置Liveness和Readiness探針

這篇文章主要介紹“如何配置Liveness和Readiness探針”，在日常操作中，相信很多人在如何配置Liveness和Readiness探針問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”如何配置Liveness和Readiness探針”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

本文將向您展示如何配置容器的存活和可讀性探針。

kubelet 使用 liveness probe（存活探針）來(lái)確定何時(shí)重啟容器。例如，當(dāng)應(yīng)用程序處于運(yùn)行狀態(tài)但無(wú)法做進(jìn)一步操作，liveness 探針將捕獲到 deadlock，重啟處于該狀態(tài)下的容器，使應(yīng)用程序在存在 bug 的情況下依然能夠繼續(xù)運(yùn)行下去。

Kubelet 使用 readiness probe（就緒探針）來(lái)確定容器是否已經(jīng)就緒可以接受流量。只有當(dāng) Pod 中的容器都處于就緒狀態(tài)時(shí) kubelet 才會(huì)認(rèn)定該 Pod處于就緒狀態(tài)。該信號(hào)的作用是控制哪些 Pod應(yīng)該作為service的后端。如果 Pod 處于非就緒狀態(tài)，那么它們將會(huì)被從 service 的 load balancer中移除。

• Before you begin

• 定義 liveness 命令

• 定義 liveness HTTP請(qǐng)求

• 定義 TCP liveness probe

• 使用命名的端口

• 定義readiness probe

• Configure Probes

• 配置 Probe

• What’s next

• 參考

Before you begin

You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using Minikube, or you can use one of these Kubernetes playgrounds:

• Katacoda

• Play with Kubernetes

To check the version, enter kubectl version.

定義 liveness 命令

許多長(zhǎng)時(shí)間運(yùn)行的應(yīng)用程序最終會(huì)轉(zhuǎn)換到 broken 狀態(tài)，除非重新啟動(dòng)，否則無(wú)法恢復(fù)。Kubernetes 提供了 liveness probe 來(lái)檢測(cè)和補(bǔ)救這種情況。

在本次練習(xí)將基于 gcr.io/google_containers/busybox鏡像創(chuàng)建運(yùn)行一個(gè)容器的 Pod。以下是 Pod 的配置文件exec-liveness.yaml：

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 配置了一個(gè)容器。periodSeconds 規(guī)定 kubelet 要每隔5秒執(zhí)行一次 liveness probe。initialDelaySeconds 告訴 kubelet 在第一次執(zhí)行 probe 之前要的等待5秒鐘。探針檢測(cè)命令是在容器中執(zhí)行 cat /tmp/healthy 命令。如果命令執(zhí)行成功，將返回0，kubelet 就會(huì)認(rèn)為該容器是活著的并且很健康。如果返回非0值，kubelet 就會(huì)殺掉這個(gè)容器并重啟它。

容器啟動(dòng)時(shí)，執(zhí)行該命令：

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"

在容器生命的最初30秒內(nèi)有一個(gè) /tmp/healthy 文件，在這30秒內(nèi) cat /tmp/healthy命令會(huì)返回一個(gè)成功的返回碼。30秒后， cat /tmp/healthy 將返回失敗的返回碼。

創(chuàng)建Pod：

kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/exec-liveness.yaml

在30秒內(nèi)，查看 Pod 的 event：

kubectl describe pod liveness-exec

結(jié)果顯示沒(méi)有失敗的 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 失敗，容器被刪掉并重新創(chuàng)建。

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秒，確認(rèn)容器已經(jīng)重啟：

kubectl get pod liveness-exec

從輸出結(jié)果來(lái)RESTARTS值加1了。

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

定義 liveness HTTP請(qǐng)求

我們還可以使用 HTTP GET 請(qǐng)求作為 liveness probe。下面是一個(gè)基于gcr.io/google_containers/liveness鏡像運(yùn)行了一個(gè)容器的 Pod 的例子http-liveness.yaml：

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: X-Custom-Header           value: Awesome       initialDelaySeconds: 3       periodSeconds: 3

該配置文件只定義了一個(gè)容器，livenessProbe 指定 kubelet 需要每隔3秒執(zhí)行一次 liveness probe。initialDelaySeconds 指定 kubelet 在該執(zhí)行第一次探測(cè)之前需要等待3秒鐘。該探針將向容器中的 server 的8080端口發(fā)送一個(gè)HTTP GET 請(qǐng)求。如果server的/healthz路徑的 handler 返回一個(gè)成功的返回碼，kubelet 就會(huì)認(rèn)定該容器是活著的并且很健康。如果返回失敗的返回碼，kubelet 將殺掉該容器并重啟它。

任何大于200小于400的返回碼都會(huì)認(rèn)定是成功的返回碼。其他返回碼都會(huì)被認(rèn)為是失敗的返回碼。

查看server的源碼：server.go.

最開(kāi)始的10秒該容器是活著的， /healthz handler 返回200的狀態(tài)碼。這之后將返回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"))
    }
})

容器啟動(dòng)3秒后，kubelet 開(kāi)始執(zhí)行健康檢查。第一次健康監(jiān)測(cè)會(huì)成功，但是10秒后，健康檢查將失敗，kubelet將殺掉和重啟容器。

創(chuàng)建一個(gè) Pod 來(lái)測(cè)試一下 HTTP liveness檢測(cè)：

kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/http-liveness.yaml

10秒后，查看 Pod 的 event，確認(rèn) liveness probe 失敗并重啟了容器。

kubectl describe pod liveness-http

定義 TCP liveness probe

第三種 liveness probe 使用 TCP Socket。 使用此配置，kubelet 將嘗試在指定端口上打開(kāi)容器的套接字。 如果可以建立連接，容器被認(rèn)為是健康的，如果不能就認(rèn)為是失敗的。

tcp-liveness-readiness.yaml

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

如您所見(jiàn)，TCP 檢查的配置與 HTTP 檢查非常相似。 此示例同時(shí)使用了 readiness 和 liveness probe。 容器啟動(dòng)后5秒鐘，kubelet將發(fā)送第一個(gè) readiness probe。 這將嘗試連接到端口8080上的 goproxy 容器。如果探測(cè)成功，則該 Pod 將被標(biāo)記為就緒。Kubelet 將每隔10秒鐘執(zhí)行一次該檢查。

如您所見(jiàn)，TCP 檢查的配置與 HTTP 檢查非常相似。 此示例同時(shí)使用了 readiness 和 liveness probe。 容器啟動(dòng)后5秒鐘，kubelet 將發(fā)送第一個(gè) readiness probe。 這將嘗試連接到端口8080上的 goproxy 容器。如果探測(cè)成功，則該 pod 將被標(biāo)記為就緒。Kubelet 將每隔10秒鐘執(zhí)行一次該檢查。

除了 readiness probe之外，該配置還包括 liveness probe。 容器啟動(dòng)15秒后，kubelet 將運(yùn)行第一個(gè) liveness probe。 就像readiness probe一樣，這將嘗試連接到 goproxy 容器上的8080端口。如果 liveness probe 失敗，容器將重新啟動(dòng)。

使用命名的端口

可以使用命名的 ContainerPort 作為 HTTP 或 TCP liveness檢查：

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
  path: /healthz
  port: liveness-port

定義readiness probe

有時(shí)，應(yīng)用程序暫時(shí)無(wú)法對(duì)外部流量提供服務(wù)。 例如，應(yīng)用程序可能需要在啟動(dòng)期間加載大量數(shù)據(jù)或配置文件。 在這種情況下，您不想殺死應(yīng)用程序，也不想發(fā)送請(qǐng)求。 Kubernetes提供了readiness probe來(lái)檢測(cè)和減輕這些情況。 Pod中的容器可以報(bào)告自己還沒(méi)有準(zhǔn)備，不能處理Kubernetes服務(wù)發(fā)送過(guò)來(lái)的流量。

Readiness probe的配置跟liveness probe很像。唯一的不同是使用 readinessProbe而不是livenessProbe。

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

Readiness probe 的 HTTP 和 TCP 的探測(cè)器配置跟 liveness probe 一樣。

Readiness 和 livenss probe 可以并行用于同一容器。 使用兩者可以確保流量無(wú)法到達(dá)未準(zhǔn)備好的容器，并且容器在失敗時(shí)重新啟動(dòng)。

Configure Probes

配置 Probe

Probe 中有很多精確和詳細(xì)的配置，通過(guò)它們您能準(zhǔn)確的控制 liveness 和 readiness 檢查：

• initialDelaySeconds：容器啟動(dòng)后第一次執(zhí)行探測(cè)是需要等待多少秒。

• periodSeconds：執(zhí)行探測(cè)的頻率。默認(rèn)是10秒，最小1秒。

• timeoutSeconds：探測(cè)超時(shí)時(shí)間。默認(rèn)1秒，最小1秒。

• successThreshold：探測(cè)失敗后，最少連續(xù)探測(cè)成功多少次才被認(rèn)定為成功。默認(rèn)是 1。對(duì)于 liveness 必須是 1。最小值是 1。

• failureThreshold：探測(cè)成功后，最少連續(xù)探測(cè)失敗多少次才被認(rèn)定為失敗。默認(rèn)是 3。最小值是 1。

HTTP probe 中可以給 httpGet設(shè)置其他配置項(xiàng)：

• host：連接的主機(jī)名，默認(rèn)連接到 pod 的 IP。您可能想在 http header 中設(shè)置 “Host” 而不是使用 IP。

• scheme：連接使用的 schema，默認(rèn)HTTP。

• path: 訪問(wèn)的HTTP server 的 path。

• httpHeaders：自定義請(qǐng)求的 header。HTTP運(yùn)行重復(fù)的 header。

• port：訪問(wèn)的容器的端口名字或者端口號(hào)。端口號(hào)必須介于 1 和 65525 之間。

對(duì)于 HTTP 探測(cè)器，kubelet 向指定的路徑和端口發(fā)送 HTTP 請(qǐng)求以執(zhí)行檢查。 Kubelet 將 probe 發(fā)送到容器的 IP 地址，除非地址被httpGet中的可選host字段覆蓋。 在大多數(shù)情況下，您不想設(shè)置主機(jī)字段。 有一種情況下您可以設(shè)置它。 假設(shè)容器在127.0.0.1上偵聽(tīng)，并且 Pod 的hostNetwork字段為 true。 然后，在httpGet下的host應(yīng)該設(shè)置為127.0.0.1。 如果您的 pod 依賴于虛擬主機(jī)，這可能是更常見(jiàn)的情況，您不應(yīng)該是用host，而是應(yīng)該在httpHeaders中設(shè)置Host頭。

到此，關(guān)于“如何配置Liveness和Readiness探針”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！