今天來還債啦:)

接續第四天 Pod 介紹。

• Why Pod?
• Pod Phase
• Container Probes

Why Pod?

在認識 Kubernetes 過程，可能會有的一些小疑惑: 為何 Kubernetes 要特別在 Container 之外包一層所謂的 Pod? 用 Container 最為管理運行的最小單位不好嗎?

主要有下列幾點原因:

1. 可以支持多容器運行: 像先前提及到的，一個 Pod 並非只能置放一個 Container，可以同時具有多個 Containers 在 Pod 中運行。
   透過下方來自官網的解釋即可知:

A multi-container Pod that contains a file puller and a web server that uses a persistent volume for shared storage between the containers.

2. 基於 multiple cooperating process 模型，此種設計讓 scaling、replication 能在 Kubernetes 中自動被管理。
3. 因應容器技術變化: Docker 到現在的 rktlet。

Pod Phase

圖取自此篇文章，透過該圖可以更容易理解 Pod 的狀態。

• Pending: 已被 Kubernetes cluster 接受，但有 Container 尚未準備好。可能與從網路上下載 Container image 花費時間有關。
• Running: Pod 已綁訂到 Node 上，且所有 Container(s) 已被建立，至少有一 Container 正在啟動/重新啟動。
• Succeeded: 所有 Container(s) 皆成功運行，並不會重啟。
• Failed: 因至少一個 Container 因故障終止，導致 Pod 內所有 Containers 皆終止。
• Unknown: 無法取得 Pod 目前狀態，通常是因與該 Pod 所在的 Node 進行通訊失敗所導致。

Container Probes

Probe 翻譯為"探針"，在 Kubernetes 中，透過 kubelet 定期對 Containers 進行診斷，可以透過執行容器內程式碼，或是發出網路請求來對 Container 進行診斷:

1. Exec: 在 Container 中執行指定的命令。
2. Grpc: 使用 gRPC 檢查，如果回應為 SERVING，則診斷為成功。
3. TCPSocket: 對指定 IP address 的 port 執行 TCP 檢查。
4. HTTPGet: 針對指定的 IP address 執行 HTTP GET 請求。

每個 probe 執行完都會有Success，Failure 或是 Unknown 其中一種結果。

今天先這樣囉~

Always listen to your heart because even though it's on your left side, it's always right.
共勉之