一、Pod資源生命週期（健康狀態檢查）

1.1、pod生命週期的介紹

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

Pod生命週期中的重要階段

• 初始化容器
• 生命周鉤子函式
  • postStart
  • preStop
• 容器探測
  • 探測型別
    • 存活狀態探測 ：liveness probe
    • 就緒狀態探測 ： readiness probe
  • 探測行為
    • ExecAction
    • TCPSocketAction
    • HTTPGetAction

1.1.1、Pod phase

• Pod的status定義在 PodStatus物件中，其中有一個phase欄位。
• Pod的執行階段是Pod在其生命週期中的簡單巨集觀概述。
• 下面是phase可能的值：
  • Pending 掛起：該狀態標識Pod沒有排程到節點上，可能下載映象耗費時間，容器還未啟動。
  • Running 執行中： Pod已經繫結到一個節點上，Pod中的容器已經全部建立，至少有一個容器正在執行，或者證處於啟動狀態或重啟狀態。
  • Succeeded 成功： Pod中所有的容器都被成功終止，並且不會被重啟。
  • Failed 失敗：Pod中的所有容器都已經終止了，並且至少有一個容器是因為失敗終止。容器退出狀態非0或被系統終止。
  • Unknown 未知： 因為某些原因無法取得Pod狀態，通常因為與Pod所在節點失去通訊造成失聯。

1.1.2、Pod 狀態

• Pod 有一個 PodStatus 物件，其中包含一個 PodCondition 陣列。 PodCondition 陣列的每個元素都有一個 type 欄位和一個 status 欄位。type 欄位是字串，可能的值有 PodScheduled、Ready、Initialized 和 Unschedulable。status 欄位是一個字串，可能的值有 True、False 和 Unknown。

1.1.3、Pod健康檢查

• 檢視官網文件，探針是有kubelet對容器狀態的一種定期監控和檢查，要執行診斷，kubelet可以呼叫由容器實現的Handler。有三種執行方式：
  • HTTPGetAction(http)：對指定埠和路徑上的容器的IP地址執行HTTP Get請求。如果狀態碼大於等於200且小於400，則認為診斷成功。
  • ExecAction(exec): 在容器內部執行指定命令，執行後退出狀態碼為0則診斷成功。
  • TCPSocketAction(tcp:): kubelet 對指定容器IP和Port進行TCP檢查，如果埠開啟，則被認為診斷成功
• 診斷狀態有三種：
  • 成功： 容器狀態健康，通過了檢測
  • 失敗： 容器未通過診斷
  • 未知： 診斷失敗，不會採取任何行動

1.1.3.1、容器探針

• 供kubelet對容器診斷的探針有兩種：
  • LivenessProbe: 存活探針，指容器是否正在執行。如果檢測失敗，則kubelet會殺死容器，並且容器會受重啟策略的影響而是否重啟， 如果容器不提供探針，則預設狀態為success。
  • ReadnessProbe: 就緒探針，指容器是否準備就緒，接受服務請求。如果就緒探針失敗，端點控制器將從與Pod匹配的所有service的端點中移除該Pod的IP 地址。初始延遲之前的就緒狀態預設是Failure，如果容器不提供就緒探針，則預設狀態為Success。

1.1.3.2、什麼時候選擇livenessProbe 存活探針和readnessProbe就緒探針？

• 如果容器中的程序能夠在出現服務故障的時候自動崩潰，那麼這種時候是不需要提供livenessProbe ，kubelet將根據Pod的restartPolicy自動執行正確的操作
• 如果希望容器在探測失敗時被殺死並重新啟動，那麼請指定一個livenessPRobe存活探針，並指定restartPolicy為Always或OnFailure。
• 如果要在探測成功才開始向Pod傳送流量，就需要指定一個readnessProbe 。在這種情況下，就緒探針可能和存活探針同時存在，這種情況下的readnessProbe意味容器在沒有接受到任何 流量的情況下啟動，並且只有在探針成功後才接收流量。如果希望容器能夠自行維護，那就指定一個readnessProbe探針，和livenessProbe探測不同的端點。
• 注意，如果只想在pod被刪除時能夠排除請求，則不一定需要使用就緒探針；在刪除Pod時，Pod將自動將自身置於未完成狀態，無論是否有就緒探針。當等待Pod中的容器停止時，Pod仍處於未完成狀態。

1.1.3.3、模板 使用exec方式指定command

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 殺掉然後重啟。

1.1.3.4、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。兩者如果同時使用的話就可以確保流量不會到達還未準備好的容器，準備好過後，如果應用程式出現了錯誤，則會重新啟動容器。

1.1.3.6、探針引數

• timeoutSeconds：探測超時時間，預設1秒，最小1秒。
• successThreshold：探測失敗後，最少連續探測成功多少次才被認定為成功。預設是 1，但是如果是liveness則必須是 1。最小值是 1。
• failureThreshold：探測成功後，最少連續探測失敗多少次才被認定為失敗。預設是 3，最小值是 1。

1.1.3.7、重啟策略

• dSpec 中有一個 restartPolicy 欄位，可能的值為 Always、OnFailure 和 Never。預設為 Always。 restartPolicy 適用於 Pod 中的所有容器。restartPolicy 僅指通過同一節點上的 kubelet 重新啟動容器。失敗的容器由 kubelet 以五分鐘為上限的指數退避延遲（10秒，20秒，40秒…）重新啟動，並在成功執行十分鐘後重置。如 Pod 文件 中所述，一旦繫結到一個節點，Pod 將永遠不會重新繫結到另一個節點。
• tartPolicy:
  • ways 容器失效時，kubelet 自動重啟該容器
  • Failure 容器終止執行且退出碼不為0時重啟
  • ver 不論狀態為何， kubelet 都不重啟該容器

4.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