Kubernetes Pod

一、Kubernetes Pod 生命周期

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

下面是 phase 可能的值：

挂起（Pending）：Pod 已被 Kubernetes 系統接受，但有一個或者多個容器鏡像尚未建立。等待時間包括排程 Pod 的時間和通過網絡下載下傳鏡像的時間，這可能需要花點時間。

運作中（Running）：該 Pod 已經綁定到了一個節點上，Pod 中所有的容器都已被建立。至少有一個容器正在運作，或者正處于啟動或重新開機狀态。

成功（Succeeded）：Pod 中的所有容器都被成功終止，并且不會再重新開機。

失敗（Failed）：Pod 中的所有容器都已終止了，并且至少有一個容器是因為失敗終止。也就是說，容器以非0狀态退出或者被系統終止。

未知（Unknown）：因為某些原因無法取得 Pod 的狀态，通常是因為與 Pod 所在主機通信失敗。

二、kubernetes （k8s）Pod容器探針和重新開機政策

探針 是由 kubelet 對容器執行的定期診斷。要執行診斷，kubelet 調用由容器實作的 Handler。有三種類型的處理程式：

ExecAction：在容器内執行指定指令。如果指令退出時傳回碼為 0 則認為診斷成功。

TCPSocketAction：對指定端口上的容器的 IP 位址進行 TCP 檢查。如果端口打開，則診斷被認為是成功的。

HTTPGetAction：對指定的端口和路徑上的容器的 IP 位址執行 HTTP Get 請求。如果響應的狀态碼大于等于200 且小于 400，則診斷被認為是成功的。

每次探測都将獲得以下三種結果之一：

成功：容器通過了診斷。

失敗：容器未通過診斷。

未知：診斷失敗，是以不會采取任何行動。

Kubelet 可以選擇是否執行在容器上運作的兩種探針執行和做出反應：

livenessProbe(存活探測):

訓示容器是否正在運作。如果存活探測失敗，則 kubelet 會殺死容器，并且容器将受到其 重新開機政策 的影響。如果容器不提供存活探針，則預設狀态為 Success。

readinessProbe(就緒探測):

訓示容器是否準備好服務請求。如果就緒探測失敗，端點控制器将從與 Pod 比對的所有 Service 的端點中删除該 Pod 的 IP 位址。初始延遲之前的就緒狀态預設為 Failure。如果容器不提供就緒探針，則預設狀态為 Success。

如果容器中的程序能夠在遇到問題或不健康的情況下自行崩潰，則不一定需要存活探針; kubelet 将根據 Pod 的restartPolicy 自動執行正确的操作。

如果您希望容器在探測失敗時被殺死并重新啟動，那麼請指定一個存活探針，并指定restartPolicy 為 Always 或 OnFailure。

如果要僅在探測成功時才開始向 Pod 發送流量，請指定就緒探針。在這種情況下，就緒探針可能與存活探針相同，但是 spec 中的就緒探針的存在意味着 Pod 将在沒有接收到任何流量的情況下啟動，并且隻有在探針探測成功後才開始接收流量。

如果您希望容器能夠自行維護，您可以指定一個就緒探針，該探針檢查與存活探針不同的端點。

請注意，如果您隻想在 Pod 被删除時能夠排除請求，則不一定需要使用就緒探針；在删除 Pod 時，Pod 會自動将自身置于未完成狀态，無論就緒探針是否存在。當等待 Pod 中的容器停止時，Pod 仍處于未完成狀态。

三、重新開機政策:

Pod的重新開機政策包括：Always、OnFailure和Never，預設值為Always:

Always： 當容器失效時，由kubelet自動重新開機該容器。

OnFailure： 當容器終止運作且退出碼不為0時，由kubelet自動重新開機該容器。

Never： 不論容器運作狀态如何，kubelet都不會重新開機該容器。

四、Pod 配置記憶體申請和限制

給容器配置記憶體申請，隻要在容器的配置檔案裡添加resources:requests就可以了。配置限制的話， 則是添加resources:limits.

如果不配置記憶體限制

如果不給容器配置記憶體限制，那下面的任意一種情況可能會出現：

容器使用記憶體資源沒有上限，容器可以使用目前節點上所有可用的記憶體資源。

容器所運作的命名空間有預設記憶體限制，容器會自動繼承預設的限制。叢集管理者可以使用這個文檔 LimitRange來配置預設的記憶體限制。

五、Pod 聲明記憶體申請和限制

給容器聲明一個CPU請求，隻要在容器的配置檔案裡包含這麼一句resources:requests就可以， 聲明一個CPU限制，則是這麼一句resources:limits.

六、Kubernetes 給 Pod 配置服務品質（QoS）等級

QoS 等級

當 Kubernetes 建立一個 Pod 時，它就會給這個 Pod 配置設定一個 QoS 等級：

Guaranteed

Burstable

BestEffort

1.> 想要給 Pod 配置設定 QoS 等級為 Guaranteed:

Pod 裡的每個容器都必須有記憶體限制和請求，而且必須是一樣的。

Pod 裡的每個容器都必須有 CPU 限制和請求，而且必須是一樣的

當出現下面的情況時，則是一個 Pod 被配置設定了 QoS 等級為 Burstable :

2.> 該 Pod 不滿足 QoS 等級 Guaranteed 的要求。

Pod 裡至少有一個容器有記憶體或者 CPU 請求。

3.> 要給一個 Pod 配置 BestEffort 的 QoS 等級, Pod 裡的容器必須沒有任何記憶體或者 CPU　的限制或請求。