Pod的生命周期 · kubernetes完整攻略

# Pod 的生命周期 ## Pod phase Pod 的 `status` 字段是一個 PodStatus 對象，PodStatus中有一個 `phase` 字段。 Pod 的相位（phase）是 Pod 在其生命周期中的簡單宏觀概述。該階段并不是對容器或 Pod 的綜合匯總，也不是為了做為綜合狀態機。 Pod 相位的數量和含義是嚴格指定的。除了本文檔中列舉的狀態外，不應該再假定 Pod 有其他的 `phase` 值。下面是 `phase` 可能的值： - 掛起（Pending）：Pod 已被 Kubernetes 系統接受，但有一個或者多個容器鏡像尚未創建。等待時間包括調度 Pod 的時間和通過網絡下載鏡像的時間，這可能需要花點時間。 - 運行中（Running）：該 Pod 已經綁定到了一個節點上，Pod 中所有的容器都已被創建。至少有一個容器正在運行，或者正處于啟動或重啟狀態。 - 成功（Succeeded）：Pod 中的所有容器都被成功終止，并且不會再重啟。 - 失敗（Failed）：Pod 中的所有容器都已終止了，并且至少有一個容器是因為失敗終止。也就是說，容器以非0狀態退出或者被系統終止。 - 未知（Unknown）：因為某些原因無法取得 Pod 的狀態，通常是因為與 Pod 所在主機通信失敗。下圖是Pod的生命周期示意圖，從圖中可以看到Pod狀態的變化。 ![Pod的生命周期示意圖（圖片來自網絡）](https://box.kancloud.cn/5a2787790272876d4956b36b9c9d28a4_1886x638.jpg) ## Pod 狀態 Pod 有一個 PodStatus 對象，其中包含一個 PodCondition 數組。 PodCondition 數組的每個元素都有一個 `type` 字段和一個 `status` 字段。`type` 字段是字符串，可能的值有 PodScheduled、Ready、Initialized、Unschedulable和ContainersReady。`status` 字段是一個字符串，可能的值有 True、False 和 Unknown。 ## 容器探針探針是由 [kubelet](https://kubernetes.io/docs/admin/kubelet/) 對容器執行的定期診斷。要執行診斷，kubelet 調用由容器實現的 [Handler](https://godoc.org/k8s.io/kubernetes/pkg/api/v1#Handler)。有三種類型的處理程序： - ExecAction：在容器內執行指定命令。如果命令退出時返回碼為 0 則認為診斷成功。 - TCPSocketAction：對指定端口上的容器的 IP 地址進行 TCP 檢查。如果端口打開，則診斷被認為是成功的。 - HTTPGetAction：對指定的端口和路徑上的容器的 IP 地址執行 HTTP Get 請求。如果響應的狀態碼大于等于200 且小于 400，則診斷被認為是成功的。每次探測都將獲得以下三種結果之一： - 成功：容器通過了診斷。 - 失敗：容器未通過診斷。 - 未知：診斷失敗，因此不會采取任何行動。 Kubelet 可以選擇是否執行在容器上運行的兩種探針執行和做出反應： - `livenessProbe`：指示容器是否正在運行。如果存活探測失敗，則 kubelet 會殺死容器，并且容器將受到其 [重啟策略](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 的影響。如果容器不提供存活探針，則默認狀態為 `Success`。 - `readinessProbe`：指示容器是否準備好服務請求。如果就緒探測失敗，端點控制器將從與 Pod 匹配的所有 Service 的端點中刪除該 Pod 的 IP 地址。初始延遲之前的就緒狀態默認為 `Failure`。如果容器不提供就緒探針，則默認狀態為 `Success`。 ### 該什么時候使用存活（liveness）和就緒（readiness）探針? 如果容器中的進程能夠在遇到問題或不健康的情況下自行崩潰，則不一定需要存活探針; kubelet 將根據 Pod 的`restartPolicy` 自動執行正確的操作。如果您希望容器在探測失敗時被殺死并重新啟動，那么請指定一個存活探針，并指定`restartPolicy` 為 Always 或 OnFailure。如果要僅在探測成功時才開始向 Pod 發送流量，請指定就緒探針。在這種情況下，就緒探針可能與存活探針相同，但是 spec 中的就緒探針的存在意味著 Pod 將在沒有接收到任何流量的情況下啟動，并且只有在探針探測成功后才開始接收流量。如果您希望容器能夠自行維護，您可以指定一個就緒探針，該探針檢查與存活探針不同的端點。請注意，如果您只想在 Pod 被刪除時能夠排除請求，則不一定需要使用就緒探針；在刪除 Pod 時，Pod 會自動將自身置于未完成狀態，無論就緒探針是否存在。當等待 Pod 中的容器停止時，Pod 仍處于未完成狀態。 ## Pod 和容器狀態有關 Pod 容器狀態的詳細信息，請參閱 PodStatus 和 ContainerStatus。請注意，報告的 Pod 狀態信息取決于當前的 ContainerState。 ## 重啟策略 PodSpec 中有一個 `restartPolicy` 字段，可能的值為 Always、OnFailure 和 Never。默認為 Always。 `restartPolicy` 適用于 Pod 中的所有容器。`restartPolicy` 僅指通過同一節點上的 kubelet 重新啟動容器。失敗的容器由 kubelet 以五分鐘為上限的指數退避延遲（10秒，20秒，40秒...）重新啟動，并在成功執行十分鐘后重置。如 [Pod 文檔](https://kubernetes.io/docs/user-guide/pods/#durability-of-pods-or-lack-thereof) 中所述，一旦綁定到一個節點，Pod 將永遠不會重新綁定到另一個節點。 ## Pod 的生命一般來說，Pod 不會消失，直到人為銷毀他們。這可能是一個人或控制器。這個規則的唯一例外是成功或失敗的 `phase` 超過一段時間（由 master 確定）的Pod將過期并被自動銷毀。有三種可用的控制器： - 使用 [Job](https://kubernetes.io/docs/concepts/jobs/run-to-completion-finite-workloads/) 運行預期會終止的 Pod，例如批量計算。Job 僅適用于重啟策略為 `OnFailure` 或 `Never` 的 Pod。 - 對預期不會終止的 Pod 使用 [ReplicationController](https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/)、[ReplicaSet](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) 和 [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) ，例如 Web 服務器。 ReplicationController 僅適用于具有 `restartPolicy` 為 Always 的 Pod。 - 提供特定于機器的系統服務，使用 [DaemonSet](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) 為每臺機器運行一個 Pod 。所有這三種類型的控制器都包含一個 PodTemplate。建議創建適當的控制器，讓它們來創建 Pod，而不是直接自己創建 Pod。這是因為單獨的 Pod 在機器故障的情況下沒有辦法自動復原，而控制器卻可以。如果節點死亡或與集群的其余部分斷開連接，則 Kubernetes 將應用一個策略將丟失節點上的所有 Pod 的 `phase` 設置為 Failed。 ## 示例 ### 高級 liveness 探針示例存活探針由 kubelet 來執行，因此所有的請求都在 kubelet 的網絡命名空間中進行。 ```yaml apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - args: - /server image: k8s.gcr.io/liveness livenessProbe: httpGet: # when "host" is not defined, "PodIP" will be used # host: my-host # when "scheme" is not defined, "HTTP" scheme will be used. Only "HTTP" and "HTTPS" are allowed # scheme: HTTPS path: /healthz port: 8080 httpHeaders: - name: X-Custom-Header value: Awesome initialDelaySeconds: 15 timeoutSeconds: 1 name: liveness ``` ### 狀態示例 - Pod 中只有一個容器并且正在運行。容器成功退出。 - 記錄完成事件。 - 如果 `restartPolicy` 為： - Always：重啟容器；Pod `phase` 仍為 Running。 - OnFailure：Pod `phase` 變成 Succeeded。 - Never：Pod `phase` 變成 Succeeded。 - Pod 中只有一個容器并且正在運行。容器退出失敗。 - 記錄失敗事件。 - 如果 `restartPolicy` 為： - Always：重啟容器；Pod `phase` 仍為 Running。 - OnFailure：重啟容器；Pod `phase` 仍為 Running。 - Never：Pod `phase` 變成 Failed。 - Pod 中有兩個容器并且正在運行。容器1退出失敗。 - 記錄失敗事件。 - 如果 restartPolicy 為： - Always：重啟容器；Pod `phase` 仍為 Running。 - OnFailure：重啟容器；Pod `phase` 仍為 Running。 - Never：不重啟容器；Pod `phase` 仍為 Running。 - 如果有容器1沒有處于運行狀態，并且容器2退出： - 記錄失敗事件。 - 如果 `restartPolicy` 為： - Always：重啟容器；Pod `phase` 仍為 Running。 - OnFailure：重啟容器；Pod `phase` 仍為 Running。 - Never：Pod `phase` 變成 Failed。 - Pod 中只有一個容器并處于運行狀態。容器運行時內存超出限制： - 容器以失敗狀態終止。 - 記錄 OOM 事件。 - 如果 `restartPolicy` 為： - Always：重啟容器；Pod `phase` 仍為 Running。 - OnFailure：重啟容器；Pod `phase` 仍為 Running。 - Never: 記錄失敗事件；Pod `phase` 仍為 Failed。 - Pod 正在運行，磁盤故障： - 殺掉所有容器。 - 記錄適當事件。 - Pod `phase` 變成 Failed。 - 如果使用控制器來運行，Pod 將在別處重建。 - Pod 正在運行，其節點被分段。 - 節點控制器等待直到超時。 - 節點控制器將 Pod `phase` 設置為 Failed。 - 如果是用控制器來運行，Pod 將在別處重建。原文地址：https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/ 翻譯：[rootsongjc](https://github.com/rootsongjc)