如果把pod看作是一臺物理電腦的話，它也有開機，關機，執行，開機中，等階段

物件在 Kubernetes 中的生命週期。

Pod 生命週期的變化，主要體現在 Pod API 物件的 Status 部分，這是它除了 Metadata 和 Spec 之外的第三個重要欄位。

其中，pod.status.phase，就是 Pod 的當前狀態，

它有如下幾種可能的情況：

Pending。這個狀態意味著，Pod 的 YAML 檔案已經提交給了 Kubernetes，API 物件已經被建立並儲存在 Etcd 當中。但是，這個 Pod 裡有些容器因為某種原因而不能被順利建立。比如，排程不成功。

Running。這個狀態下，Pod 已經排程成功，跟一個具體的節點繫結。它包含的容器都已經建立成功，並且至少有一個正在執行中。Succeeded。這個狀態意味著，Pod 裡的所有容器都正常執行完畢，並且已經退出了。這種情況在執行一次性任務時最為常見。

Failed。這個狀態下，Pod 裡至少有一個容器以不正常的狀態（非 
 
0 的返回碼）退出。這個狀態的出現，意味著你得想辦法 Debug 這個容器的應用，比如檢視 Pod 的 Events 和日誌。

Unknown。這是一個異常狀態，意味著 Pod 的狀態不能持續地被 kubelet 彙報給 kube-apiserver，這很有可能是主從節點（Master 和 Kubelet）間的通訊出現了問題。

更進一步地，Pod 物件的 Status 欄位，還可以再細分出一組 Conditions。

這些細分狀態的值包括：PodScheduled、Ready、Initialized，以及 Unschedulable。它們主要用於描述造成當前 Status 的具體原因是什麼。

比如，Pod 當前的 Status 是 Pending，對應的 Condition 是 Unschedulable，這就意味著它的排程出現了問題。

而其中，Ready 這個細分狀態非常值得我們關注：它意味著 Pod 不僅已經正常啟動（Running 狀態），而且已經可以對外提供服務了。

這兩者之間（Running 和 Ready）是有區別的。

Pod 的這些狀態資訊，是我們判斷應用執行情況的重要標準，尤其是 Pod 進入了非“Running”狀態後，你一定要能迅速做出反應，根據它所代表的異常情況開始跟蹤和定位，而不是去手忙腳亂地查閱文件。