Pod生命週期和健康檢查

Pod生命週期和健康檢查

Pod的生命週期涵蓋了前面所說的PostStart 和 PreStop在內

Pod phase

Pod的status定義在 PodStatus對象中，其中有一個phase字段。

Pod的運行階段是Pod在其生命週期中的簡單宏觀概述。

下面是phase可能的值：

• Pending 掛起：該狀態標識Pod沒有調度到節點上，可能下載鏡像耗費時間，容器還未啓動。
• Running 運行中： Pod已經綁定到一個節點上，Pod中的容器已經所有建立，至少有一個容器正在運行，或者證處於啓動狀態或重啓狀態。
• Succeeded 成功： Pod中全部的容器都被成功終止，而且不會被重啓。
• Failed 失敗：Pod中的全部容器都已經終止了，而且至少有一個容器是由於失敗終止。容器退出狀態非0或被系統終止。
• Unknown 未知： 由於某些緣由沒法取得Pod狀態，一般由於與Pod所在節點失去通訊形成失聯。

Pod 狀態

Pod 有一個 PodStatus 對象，其中包含一個 PodCondition 數組。 PodCondition 數組的每一個元素都有一個 type 字段和一個 status 字段。type 字段是字符串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。status 字段是一個字符串，可能的值有 True、False 和 Unknown。

Pod健康檢查

查看官網文檔，探針是有kubelet對容器狀態的一種按期監控和檢查，要執行診斷，kubelet能夠調用由容器實現的Handler。有三種執行方式：

• HTTPGetAction(http)：對指定端口和路徑上的容器的IP地址執行HTTP Get請求。若是狀態碼大於等於200且小於400，則認爲診斷成功。
• ExecAction(exec): 在容器內部執行指定命令，執行後退出狀態碼爲0則診斷成功。
• TCPSocketAction(tcp:): kubelet 對指定容器IP和Port進行TCP檢查，若是端口打開，則被認爲診斷成功

診斷狀態有三種：

• 成功： 容器狀態健康，經過了檢測
• 失敗： 容器未經過診斷
• 未知： 診斷失敗，不會採起任何行動

容器探針

供kubelet對容器診斷的探針有兩種：

• LivenessProbe: 存活探針，指容器是否正在運行。若是檢測失敗，則kubelet會殺死容器，而且容器會受重啓策略的影響而是否重啓， 若是容器不提供探針，則默認狀態爲success。
• ReadnessProbe: 就緒探針，指容器是否準備就緒，接受服務請求。若是就緒探針失敗，端點控制器將從與Pod匹配的全部service的端點中移除該Pod的IP 地址。初始延遲以前的就緒狀態默認是Failure，若是容器不提供就緒探針，則默認狀態爲Success。

何時選擇livenessProbe 存活探針和readnessProbe就緒探針？

若是容器中的進程可以在出現服務故障的時候自動崩潰，那麼這種時候是不須要提供livenessProbe ，kubelet將根據Pod的restartPolicy自動執行正確的操做

若是但願容器在探測失敗時被殺死並從新啓動，那麼請指定一個livenessPRobe存活探針，並指定restartPolicy爲Always或OnFailure。

若是要在探測成功纔開始向Pod發送流量，就須要指定一個readnessProbe 。在這種狀況下，就緒探針可能和存活探針同時存在，這種狀況下的readnessProbe意味容器在沒有接受到任何 流量的狀況下啓動，而且只有在探針成功後才接收流量。若是但願容器可以自行維護，那就指定一個readnessProbe探針，和livenessProbe探測不一樣的端點。

注意，若是隻想在pod被刪除時可以排除請求，則不必定須要使用就緒探針；在刪除Pod時，Pod將自動將自身置於未完成狀態，不管是否有就緒探針。當等待Pod中的容器中止時，Pod仍處於未完成狀態。

模板 使用exec方式

apiVersion: v1
kind: Pod
metadata: 
  name: probe
spec:
  containers:
  - name: probe
    image: busybox
    argx:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command: 
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5        #等待容器啓動5秒後發起探針
      periodSeconds: 5              #發起探針的間隔5秒一次

使用kubectl 部署這個yaml文件，建立一個Pod,能夠發如今啓動完成後等待5秒後開始發起探針診斷，每隔5秒後發起一次診斷，而這裏使用的是exec方式，在30秒後容器會執行刪除/tmp/healthy 文件操做，這以後再發起探針診斷則診斷失敗，容器將被kubelet 殺掉而後重啓。

livenessProbe和readnessProbe一塊兒使用

apiVersion: v1
kind: Pod
metadata:
  name: probe-http
  label:
    app: probe-http
sepc:
  containers:
  - name: probe-http
    image: nginx
    containerPort:
    - name: http
      port: 80
    livenessProbe:
      # 當沒有定義 "host" 時，使用 "PodIP"
        # host: my-host
        # 當沒有定義 "scheme" 時，使用 "HTTP" scheme 只容許 "HTTP" 和 "HTTPS"
        # scheme: HTTPS
        path: /     #路徑能夠是想要檢查的能訪問到的任何路徑，如：/healthy
        port: 80
     #   httpHeaders:   設置http請求頭
     #   - name: X-Custom-Header
     #     value: Awesome
      initialDelaySeconds: 15
      timeoutSeconds: 1  #超時時間
    readnessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 20

從上面的YAML文件咱們能夠看出readiness probe的配置跟liveness probe很像，基本上一致的。惟一的不一樣是使用readinessProbe而不是livenessProbe。二者若是同時使用的話就能夠確保流量不會到達還未準備好的容器，準備好事後，若是應用程序出現了錯誤，則會從新啓動容器。

探針參數：

* timeoutSeconds：探測超時時間，默認1秒，最小1秒。
* successThreshold：探測失敗後，最少連續探測成功多少次才被認定爲成功。默認是 1，可是若是是`liveness`則必須是 1。最小值是 1。
* failureThreshold：探測成功後，最少連續探測失敗多少次才被認定爲失敗。默認是 3，最小值是 1。

重啓策略

PodSpec 中有一個 restartPolicy 字段，可能的值爲 Always、OnFailure 和 Never。默認爲 Always。 restartPolicy 適用於 Pod 中的全部容器。restartPolicy 僅指經過同一節點上的 kubelet 從新啓動容器。失敗的容器由 kubelet 以五分鐘爲上限的指數退避延遲（10秒，20秒，40秒…）從新啓動，並在成功執行十分鐘後重置。如 Pod 文檔 中所述，一旦綁定到一個節點，Pod 將永遠不會從新綁定到另外一個節點。

restartPolicy:

• Always 容器失效時，kubelet 自動重啓該容器
• OnFailure 容器終止運行且退出碼不爲0時重啓
• Never 不論狀態爲什麼， kubelet 都不重啓該容器

Pod 的生命

通常來講，Pod 不會消失，直到人爲銷燬他們。這多是一我的或控制器。這個規則的惟一例外是成功或失敗的 phase 超過一段時間（由 master 肯定）的Pod將過時並被自動銷燬。

有三種可用的控制器：

• 使用 Job 運行預期會終止的 Pod，例如批量計算。Job 僅適用於重啓策略爲 OnFailure 或 Never 的 Pod。
• 對預期不會終止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服務器。 ReplicationController 僅適用於具備 restartPolicy 爲 Always 的 Pod。
• 提供特定於機器的系統服務，使用 DaemonSet 爲每臺機器運行一個 Pod 。

全部這三種類型的控制器都包含一個 PodTemplate。建議建立適當的控制器，讓它們來建立 Pod，而不是直接本身建立 Pod。這是由於單獨的 Pod 在機器故障的狀況下沒有辦法自動復原，而控制器卻能夠。

若是節點死亡或與集羣的其他部分斷開鏈接，則 Kubernetes 將應用一個策略將丟失節點上的全部 Pod 的 phase 設置爲 Failed