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

新干網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián),新干網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為新干上千多家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的新干做網(wǎng)站的公司定做！

當(dāng)你使用kuberentes的時(shí)候，有沒有遇到過Pod在啟動(dòng)后一會(huì)就掛掉然后又重新啟動(dòng)這樣的惡性循環(huán)？你有沒有想過kubernetes是如何檢測(cè)pod是否還存活？雖然容器已經(jīng)啟動(dòng)，但是kubernetes如何知道容器的進(jìn)程是否準(zhǔn)備好對(duì)外提供服務(wù)了呢？讓我們通過kuberentes官網(wǎng)的這篇文章Configure Liveness and Readiness Probes，來一探究竟。

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

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

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

定義 liveness命令

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

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

apiVersion: v1kind: Podmetadata:
  labels:
    test: liveness
  name: liveness-execspec:
  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配置了一個(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é)果顯示沒有失敗的liveness probe：

FirstSeen    LastSeen    Count   From            SubobjectPath           Type        Reason      Message--------- --------    -----   ----            -------------           --------    ------      -------24s       24s     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned liveness-exec to worker023s       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

啟動(dòng)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 worker036s       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 86849c15382e2s        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é)果來RESTARTS值加1了。

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

定義一個(gè)liveness HTTP請(qǐng)求

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

apiVersion: v1kind: Podmetadata:
  labels:
    test: liveness
  name: liveness-httpspec:
  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

該配置文件只定義了一個(gè)容器，livenessProbe 指定kubelete需要每隔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.

最開始的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開始執(zhí)行健康檢查。第一次健康監(jiān)測(cè)會(huì)成功，但是10秒后，健康檢查將失敗，kubelet將殺掉和重啟容器。

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

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，確認(rèn)liveness probe失敗并重啟了容器。

kubectl describe pod liveness-http

定義TCP liveness探針

第三種liveness probe使用TCP Socket。 使用此配置，kubelet將嘗試在指定端口上打開容器的套接字。 如果可以建立連接，容器被認(rèn)為是健康的，如果不能就認(rè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: 8080livenessProbe:
  httpGet:
  path: /healthz
  port: liveness-port

定義readiness探針

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

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可以并行用于同一容器。 使用兩者可以確保流量無法到達(dá)未準(zhǔn)備好的容器，并且容器在失敗時(shí)重新啟動(dòng)。

配置Probe

Probe中有很多精確和詳細(xì)的配置，通過它們你能準(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: 訪問的HTTP server的path。

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

• port：訪問的容器的端口名字或者端口號(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上偵聽，并且Pod的hostNetwork字段為true。 然后，在httpGet下的host應(yīng)該設(shè)置為127.0.0.1。 如果你的pod依賴于虛擬主機(jī)，這可能是更常見的情況，你不應(yīng)該是用host，而是應(yīng)該在httpHeaders中設(shè)置Host頭。

到此，關(guān)于“Kubernetes中怎么配置Pod的liveness和readiness探針”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！