前言

大家好，我是秋意零。

上一篇中介紹了，Pod 的服務(wù)對象，從而對 Pod 有了更深的理解；

今天的主題是 Pod 健康檢查和恢復(fù)機(jī)制，我們將結(jié)束 Pod 的內(nèi)容。

最近搞了一個扣扣群，旨在技術(shù)交流、博客互助，希望各位大佬多多支持！在我主頁推廣區(qū)域，如圖：

文章底部推廣區(qū)域，如圖：

?? 簡介

• ?? 個人主頁： 秋意零
• ?? 個人介紹：在校期間參與眾多云計算相關(guān)比賽，如：?? “省賽”、“國賽”，并斬獲多項獎項榮譽(yù)證書
• ?? 目前狀況：24 屆畢業(yè)生，拿到一家私有云（IAAS）公司 offer，暑假開始實習(xí)
• ?? 賬號：各個平臺， 秋意零 賬號創(chuàng)作者、 云社區(qū) 創(chuàng)建者
• ??歡迎大家：歡迎大家一起學(xué)習(xí)云計算，走向年薪 30 萬

系列文章目錄

【云原生|探索 Kubernetes-1】容器的本質(zhì)是進(jìn)程
【云原生|探索 Kubernetes-2】容器 Linux Cgroups 限制
【云原生|探索 Kubernetes 系列 3】深入理解容器進(jìn)程的文件系統(tǒng)
【云原生|探索 Kubernetes 系列 4】現(xiàn)代云原生時代的引擎
【云原生|探索 Kubernetes 系列 5】簡化 Kubernetes 的部署，深入解析其工作流程

正文開始：

• 快速上船，馬上開始掌舵了（Kubernetes），距離開船還有 3s，2s，1s…

一、健康檢查

在 Kubernetes 中，Pod 的狀態(tài)決定不了服務(wù)的狀態(tài)，如：Pod 的狀態(tài)是 running，而一個 Web 服務(wù) Down 掉了，那么 Pod 對它是無感知的。本來我們理想是，這種服務(wù) Down 掉之后，隨之影響 Pod 的狀態(tài)。所以我就需要==采用 Pod 的健康檢查 “探針”（Probe），這樣，kubelet 就會根據(jù)這個 Probe 的返回值決定這個容器的狀態(tài)，而不是直接以容器鏡像是否運(yùn)行（來自 Docker 返回的信息）作為依據(jù)。是生產(chǎn)環(huán)境中保證應(yīng)用健康存活的重要手段。

健康檢查 “探針”（Probe）屬于 Pod 生命周期范疇。

在 【探索 Kubernetes|作業(yè)管理篇 系列 8】探究 Pod 的 API 對象屬性級別與重要字段用法，這篇中就介紹過 Pod 生命周期，遺忘了可以回頭看看。

Kubernetes 中的 Pod 探針可以使用以下三種方式進(jìn)行健康檢查：

• Exec 探針（Exec Probe）：通過在容器內(nèi)執(zhí)行命令來檢查容器的健康狀態(tài)。Kubernetes 將定期執(zhí)行指定的命令，并根據(jù)命令的退出狀態(tài)碼來判斷容器是否健康。
• HTTP 探針（HTTP Probe）：通過向容器內(nèi)指定的 HTTP 端點發(fā)送 HTTP 請求來檢查容器的健康狀態(tài)。Kubernetes 將檢查請求的響應(yīng)狀態(tài)碼，只有在響應(yīng)碼在指定的成功范圍內(nèi)時才認(rèn)為容器是健康的。
• TCP 探針（TCP Probe）：通過嘗試建立到容器內(nèi)指定端口的 TCP 連接來檢查容器的健康狀態(tài)。如果連接成功建立，則認(rèn)為容器是健康的；否則，認(rèn)為容器是不健康的。

Exec 方式

舉個栗子：

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: test-liveness-exec
spec:
  containers:
  - name: liveness
    image: nginx
    imagePullPolicy: IfNotPresent
    args:
    - /bin/sh
    - -c
    - touche /usr/share/nginx/html/test.html; sleep 15; rm -rf /usr/share/nginx/html/test.html
    livenessProbe:
      exec:
        command:
        - cat
        - /usr/share/nginx/html/test.html
      initialDelaySeconds: 5
      periodSeconds: 5

這個 Pod 中，最開始會創(chuàng)建 一個 /usr/share/nginx/html/test.html 文件，過 15 s 之后會刪除這個 /usr/share/nginx/html/test.html 文件。

同時，定義了一個 livenessProbe（健康檢查探針），它的動作是 exec 進(jìn)去容器執(zhí)行 cat /usr/share/nginx/html/test.html 查看文件內(nèi)容，如果命令成功執(zhí)行那么返回值會是 0，否則就不是 0，返回為 0 就代表當(dāng)前服務(wù)是健康的。

注意：這個健康檢查，在容器啟動 5 s 后開始執(zhí)行（initialDelaySeconds: 5），每 5 s 執(zhí)行一次（periodSeconds: 5）。所以，可以將 initialDelaySeconds 和 periodSeconds 看作是用來控制健康檢查動作的屬性。

首先，創(chuàng)建這個 Pod：

[root@master01 yaml]# kubectl apply -f liveness.yaml
pod/test-liveness-exec created

然后，查看這個 Pod 的狀態(tài)，使用 -w 監(jiān)控狀態(tài)：

[root@master01 yaml]# kubectl get -f liveness.yaml -w
NAME                 READY   STATUS    RESTARTS   AGE
test-liveness-exec   1/1     Running   0          7s

test-liveness-exec   0/1     Completed   0          16s
test-liveness-exec   1/1     Running     1 (1s ago)   17s
test-liveness-exec   0/1     Completed   1 (16s ago)   32s

上述中，可以看到 16s 時，Pod 的狀態(tài)就不在是 Running 而是 Completed，這時我們查看 Events 事件：

• 看到我們，使用健康檢查的來檢測文件不存在，說明此時 Pod 的狀態(tài)是不健康的。
• 而現(xiàn)在 Pod 的狀態(tài)是 Completed 這就和 Pod 的重啟策略有關(guān)了。

kubectl describe -f liveness.yaml

我們查看 17 s 之后，Pod 的狀態(tài)變?yōu)榱?Runing，說明了 Pod 以及重新啟動過一次了，RESTARTS 字段可以看出重新啟動的次數(shù)，如下：

[root@master01 yaml]# kubectl get -f liveness.yaml -w
NAME                 READY   STATUS    RESTARTS   AGE
test-liveness-exec   1/1     Running   0          7s

test-liveness-exec   0/1     Completed   0          17s
test-liveness-exec   1/1     Running     1 (2s ago)   18s
test-liveness-exec   1/1     Running     2 (1s ago)   33s

這時就有個疑問，最開始 Pod 沒有進(jìn)入 Failed 狀態(tài)，而是進(jìn)入 Completed 再保持 Running 狀態(tài)。這是為什么呢？這就是 Pod 的重啟策略（restartPolicy），也就是 Pod 的恢復(fù)機(jī)制。

HTTP 方式

cat > liveness-http.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: web-app
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 10
EOF

可以看到，我們 liveness-http 方式的 Pod，一直在運(yùn)行（健康），并沒有重啟。

[root@master01 yaml]# kubectl get -f liveness-http.yaml
NAME     READY   STATUS    RESTARTS   AGE
my-pod   1/1     Running   0          3m57s

TCP 方式

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 10

二、就緒檢測

就緒檢測（Readiness Probe）是 Kubernetes 中的一項功能，用于確定 Pod 是否已準(zhǔn)備好接收流量和處理請求。就緒檢測主要用于控制 Pod 在啟動后何時被添加到服務(wù)負(fù)載均衡器中，以確保只有處于就緒狀態(tài)的 Pod 才能接收到流量。

這部分內(nèi)容，會在講解 Service 時重點介紹。

三、恢復(fù)機(jī)制

restartPolicy。它是 Pod 的 Spec 部分的一個標(biāo)準(zhǔn)字段（pod.spec.restartPolicy），默認(rèn)值是 Always，即：任何時候這個容器發(fā)生了異常，它一定會被重新創(chuàng)建。

*需要強(qiáng)調(diào)的是：

• Pod 的恢復(fù)過程，永遠(yuǎn)都是發(fā)生在當(dāng)前節(jié)點上，而不會跑到別的節(jié)點上去。
• 事實上，一旦一個 Pod 與一個節(jié)點（Node）綁定，除非這個綁定發(fā)生了變化（pod.spec.node 字段被修改），否則它永遠(yuǎn)都不會離開這個節(jié)點。
• 這也就意味著，如果這個宿主機(jī)宕機(jī)了，這個 Pod 也不會主動遷移到其他節(jié)點上去。

而如果你想讓 Pod 出現(xiàn)在其他的可用節(jié)點上，就必須使用 Deployment 這樣的 “控制器” 來管理 Pod，哪怕只需要一個 Pod 副本。

Pod 和 Deployment 的區(qū)別：如果 Pod 所在 Node 異常，那么該 Pod 不會被遷移到其他節(jié)點；而 Deployment 會由 Kubernetes 負(fù)責(zé)調(diào)度保障業(yè)務(wù)正常運(yùn)行，會重新調(diào)度新 Node 節(jié)點運(yùn)行。

可以通過設(shè)置 restartPolicy，改變 Pod 的恢復(fù)策略，取值如下：

• Always：在任何情況下，只要容器不在運(yùn)行狀態(tài)，就自動重啟容器；
• OnFailure: 只在容器 異常時才自動重啟容器；
• Never: 從來不重啟容器。

在實際使用時，我們需要根據(jù)應(yīng)用運(yùn)行的特性，合理設(shè)置這三種恢復(fù)策略。

比如，一個 Pod，它只計算 1+1=2，計算完成輸出結(jié)果后退出，變成 Succeeded 狀態(tài)。這時，你如果再用 restartPolicy=Always 重啟這個 Pod 的容器，就沒有任何意義了，所以這種情況使用 OnFailure 策略。

而如果你要關(guān)心這個容器退出后的上下文環(huán)境，比如容器退出后的日志、文件和目錄，就需要將 restartPolicy 設(shè)置為 Never。因為一旦容器被自動重新創(chuàng)建，這些內(nèi)容就有可能丟失掉了（被垃圾回收了）。

Kubernetes 官方文檔中，總結(jié)了一堆的情況。實踐上，只需要記住下面兩個基本的設(shè)計原理即可：

• 只要 Pod 的 restartPolicy 指定的策略允許重啟異常的容器（Always、OnFailure），那么這個 Pod 就會保持 Running 狀態(tài)。否則，Pod 就會進(jìn)入 Failed 狀態(tài) 。
• 對于包含多個容器的 Pod，只有它里面所有的容器都進(jìn)入異常狀態(tài)后，Pod 才會進(jìn)入 Failed 狀態(tài)。在此之前，Pod 都是 Running 狀態(tài)。

總結(jié)

主要講解了，Pod 的健康檢查的基本概率，以及 Exec、HTTP、TCP 三種使用方式；

接著講解了 Pod 的恢復(fù)機(jī)制，我們知道了，實際上 Pod 的恢復(fù)機(jī)制就是 Pod 的三種重啟策略。

至此 Pod 的內(nèi)容也基本介紹完了，目前剩下就緒檢查的概率，這個后續(xù)會說明。

下一章將是控制器部分的內(nèi)容。

最后：技術(shù)交流、博客互助，點擊下方或主頁推廣加入哦??！

文章來源地址http://www.zghlxwxcb.cn/news/detail-493059.html

到了這里，關(guān)于【探索 Kubernetes|作業(yè)管理篇 系列 10】Pod 健康檢查和恢復(fù)機(jī)制的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！