昨天我們介紹了當使用 kubectl 指令建立 Pod 時，Control Plane 如何對請求進行驗證，並將配置持久化到資料庫中，接著透過調度演算法選擇合適的 Node，並將 Pod 與該 Node 綁定（Binding）。而今天我們將繼續探討 Worker Node 是如何將 Pod 真正建立出來的過程。
圖檔來源 Kubernetes 官方文件
圖檔來至: itnext.io/what-happens-when-you-create-a-pod-in-kubernetes
每個 Worker Node 上都會運行一個叫 kubelet 的 Process，負責監控和管理該 Node 上的 Pod。當 kube-apiserver 通知 kubelet 有新的 Pod 被綁定到該 Node 時，kubelet 會觸發 Pod 的建立流程。
該流程會透過使用 CRI、CNI、CSI 這三個 interface，將建立 Pod 的任務分派給底層的實現軟體。
CRI (Container Runtime Interface)：Kubernetes 用來與 Container Runtime 溝通，負責執行 Pod 的啟動、停止等操作。
📘 常見的 Container Runtime 包括 containerd 和 CRI-O，這些軟體負責容器的建立、啟動、停止和銷毀。
CNI (Container Network Interface)：Kubernetes 用來管理 Pod 的網路，為 Pod 分配內部 IP，並確保 Pod 能與其他 Pod 以及外部世界進行網路通訊。
CSI (Container Storage Interface)：Kubernetes 用來管理存儲資源的生命週期，例如，當 Pod 需要 Volume 資源時，Kubernetes 會透過 CSI 將存儲空間與 Pod 綁定。
📘 Kubernetes 透過這些標準接口，而不是依賴特定的實作，來完成 Pod 的建立和管理，使得 Kubernetes 管理者可以根據需求替換不同的實現軟體。
簡單來說，Kubernetes 透過：
當這些步驟完成後，Pod 及其容器便正式在該 Worker Node 上運行。
圖檔來至: itnext.io/what-happens-when-you-create-a-pod-in-kubernetes
最後 kubelet 會將該 Pod 的詳細資訊(IP、狀態) 回報到 Control Plane (透過 kube-apiserver 儲存到 etcd)。
到這裡，這個 Pod 的初始化過程基本上算是完成了。如果該 Pod 中的容器運行正常，對於長期運行的 Pod（如 Deployment），Pod 的狀態會變為 Running。而對於一次性任務的 Pod（如 Job），當所有容器成功完成任務後，Pod 的狀態會變為 Succeeded。
若在執行 kubectl get pod 時，發現 Pod 的狀態為：
ImagePullBackOff：這代表 CRI 無法取得該 Pod 定義的 container image。建議檢查以下幾點：
CrashLoopBackOff：這代表 Pod 的容器持續崩潰。可以透過 kubectl describe pod {pod-name} 檢查具體原因，通常可能是：
kubectl logs {pod-name} 查看容器的運行日誌整個 Pod 部署的完整流程可以參考下圖，讓你快速了解 Kubernetes 的各個組件如何協同合作來完成 Pod 的部署：
圖片來源：The journey of a Pod: A guide to the world of Pod Lifecycle
如果你對 kubelet 如何與 CRI、CNI 互動感興趣，可以參考下圖，進一步了解它們之間的運作原理：
圖片來源：The birth story of the kubernetes pods
到這裡，大家可能會發現 kube-proxy 這個 Worker Node 的核心組件，並沒有在上述流程中出現。明天我們將深入介紹 kube-proxy，這個在 Kubernetes 中不可或缺的組件，看看它如何在網路流量轉發中發揮作用。
iThome鐵人賽
看影片追技術