Pod對象自從建立開始至其終止退出的時間範圍稱為其聲明周期。在這段時間中，Pod會處于多種不同的狀态，并執行一些操作：
1.其中，建立主容器（main container）為必需的操作。2.其它可選的操作還包括初始化容器（init container）3.容器啟動後鈎子（post start hook）4.容器的存活性探測（liveness probe）5.就緒性探測（readiness probe）6.以及容器終止前鈎子（pre stop hook）等7.這些操作是否執行則取決于 Pod 的定義。
Pod的相位
無論是使用者手動建立的Pod，還是通過Deployment等控制器建立的Pod，Pod總是應該處于其生命程序中以下幾個相位（phase）之一。
•pending：API Server建立了Pod資源對象并已存入etcd中，但它尚未被排程完成，或仍處于從倉庫下載下傳鏡像的過程中。•Succeeded：Pod中的所有容器都已經成功終止并且不會被重新開機。•Failed：所有容器都已經被終止，但至少有一個容器終止失敗，即容器傳回非0值的退出狀态或已經被系統終止。•Unknown：API Server無法正常擷取到Pod對象的狀态資訊，通常是由于其無法與所在的工作節點的kubelet通信所緻。
Pod相位是在其生命周期中的宏觀概述，而非對容器或Pod對象的綜合彙總，而且相位的數量和含義被嚴格界定，它僅包含上面列舉的相位值。
Pod的建立過程
Pod是Kubernetes的基礎單元，了解它的建立過程對于了解系統運作大有幫助，下圖中描述了一個Pod資源對象的典型過程。
1.使用者通過kubectl或者其他API用戶端送出Pod Spec給API Server。2.API Server将Pod對象的相關資訊存入etcd中。3.待寫入etcd操作完成，etcd将寫入操作完成資訊發送給API Server。4.API Server将etcd寫入完成資訊傳回給kubectl或者其他用戶端。5.kube-scheduler監聽到API Server要建立一個新的Pod，然後開始對Pod進行排程綁定到Node。6.綁定Node成功後，kube-scheduler将bind結果傳回給API Server。7.API Server将bind資訊存儲到etcd系統中。8.etcd将存儲結果傳回給API Server。9.API Server告知kube-scheduler排程Pod資訊已存儲完成。10.kubelet也在一直監聽API Server，是以kubelet從API Server得知有一個Pod被排程到目前Node上，此時API Server也在監kubelet的資訊。11.kubelet調用目前節點的Docker來啟動容器。12.容器啟動成功後，docker将啟動狀态傳回給kubelet。13.kubelet收到docker傳回的容器狀态資訊後，将容器狀态資訊更新給API Server。14.API Server将Pod更新資訊寫入到etcd中。15.etcd寫入後将寫入結果傳回給API Server。16.API Server将确認資訊發送至相關的kubelet，事件将通過它被接受。
Pod生命周期中的重要行為
除了建立應用容器（主容器及其他輔助容器）之外，使用者還可以為Pod對象定義其生命周期中的多種行為，如初始化容器、存活性探測及就緒性探測等。
初始化容器
初始化容器(init container)即應用程式的主容器啟動之前要運作的容器，常用于為主容器執行一些預置操作，他們具有兩種典型的特征。1） 初始化容器必須運作完成直至結束，若某初始化容器運作失敗，那麼Kubernetes需要重新開機它直到成功完成。2） 每個初始化容器都必須按定義的順序串行運作容器，隻有當初始化容器運作無異常過後，才能啟動業務容器，業務容器啟動順序可以并發啟動。
如果Pod的 spec.restartPolicy 重新開機政策字段為 "Never",那麼運作失敗的初始化容器不會被重新開機。後面會講解關于Pod的重新開機政策。
Pod資源的 “spec.initContainers” 字段以清單的形式定義可用的初始化容器，下面的資源清單僅是一個初始化容器的使用示例。
cat init-pod.yamlapiVersion: v1kind: Podmetadata: name : nginx-pod-testspec: containers: - name: nginx-containers image: nginx:latest initContainers: - name: init-container image: busybox:latest command: ['sh', '-c', 'sleep 10'] 檢視Pod狀态資訊
#可以看到Pod正在初始化 kubectl get pods -o wide | grep nginx-pod nginx-pod-test 0/1 PodInitializing 0 38s 10.244.3.58 k8s-node01 <none> <none> #Pod已經正常運作 kubectl get pods -o wide | grep nginx-pod nginx-pod-test 1/1 Running 0 63s 10.244.3.58 k8s-node01 <none> <none> #檢視容器運作的詳細資訊 kubectl describe pods/nginx-pod-test 生命周期的鈎子函數
生命周期鈎子函數(lifecycle hook)是程式設計語言(如 Angular)中常用的生命周期管理元件，它實作了程式運作周期中關鍵時刻的可見性，并賦予使用者為此采取某種行動的能力，容器生命周期鈎子使它能夠感覺其自身生命周期管理中的事件，并在相應的時刻到來時，運作由使用者指定的代碼或者指令，Kubernetes為容器提供了兩種生命周期的鈎子。
•postStart：用于容器建立完成之後立即運作的鈎子處理器（handler），不過Kubernetes無法確定它一定會于容器中的ENTRYPOINT之前運作。•preStop：用于容器終止操作之前立即運作的鈎子處理器，它以同步的方式調用，是以在其完成之前會阻塞删除容器操作的調用。
鈎子處理器的實作方式有
Exec
和
HTTP
兩種，前一種在鈎子事件觸發時直接在目前容器中運作由使用者定義的指令，後一種則是在目前容器中向某URL發起HTTP請求。postStart和preStop處理器定義在容器的spec.lifecycle嵌套字段中，定義方法如下資源清單所示。
cat hook-pod.yamlapiVersion: v1kind: Podmetadata: name: lifecycle-demospec: containers: - name: lifecycle-container image: nginx:latest lifecycle: postStart: exec: command: ["/bin/sh", "-c", "echo 'lifecycle hooks handler' > /usr/share/nginx/html/test.html"] 檢視Pod狀态
#建立Pod kubectl apply -f hook-pod.yaml #檢視Pod狀态 kubectl get pods -o wide | grep lifecycle-demo lifecycle-demo 1/1 Running 0 19s 10.244.3.60 k8s-node01 <none> <none> #通路我們在容器啟動後執行指令的結果 curl http://10.244.3.60/test.html lifecycle hooks handler Pod的終止過程
Pod對象代表了在Kubernetes叢集節點上運作的程序，它可能曾用于處理生産資料或向使用者提供服務等，于是，當Pod本身不在具有存在的價值時，如何将其優雅地終止就顯得尤為重要了，而使用者也需要能夠在正常送出删除操作後可以獲知其何時開始終止并最終完成。操作中，當使用者送出了删除請求之後，系統就會進行強制删除操作的寬限期倒計時，并将TERM資訊發送給Pod對象中的每個容器的主程序。寬限期倒計時結束後，這些程序将收到強制終止的KILL資訊，Pod對象随即也将由API Server删除。如果在等待程序終止的過程中，kubelet或容器管理器發生了重新開機，那麼終止操作會重新獲得一個滿額的删除寬限期并重新執行删除操作。
如下圖所示，一個典型的Pod對象終止流程具體如下。