今日目標

• 理解 Kubernetes 的最小運算與調度單位：Pod。
• 搞懂「為什麼 K8s 不直接管理 Container，而是要封裝成 Pod？」。
• 掌握 Pod 的底層資源共享機制（Network 與 Storage）。
• 認識 Multi-Container Pod 的經典應用模式（Sidecar Pattern）。

什麼是 Pod？

在 Docker 的世界中，最基本的執行單位是 Container（容器）。但當來到 Kubernetes 時，你會發現官方文檔與指令中操作的都是 Pod。

Pod 是 Kubernetes 中能夠建立、部署與調度的最小原子單位。

簡單用一個比喻來理解：

• Container 就像是一顆「豌豆」。
• Pod 就像是包裹著豌豆的「豆莢（Pod）」。

一個 Pod 可以只包含一顆豌豆（單容器 Pod，這是最常見的情況），也可以包含多顆緊密協同工作的豌豆（多容器 Pod）。但在 Kubernetes 的眼裡，它調度與分配資源時，永遠是「整顆豆莢」一起搬移與運行的。

核心疑問：為什麼不直接管理 Container？

這是很多初學者（包括我自己）剛接觸 K8s 時最常問的問題：既然 Docker 已經把應用程式打包成容器了，為什麼 K8s 還要在外面套一層 Pod？

主要有三大關鍵原因：

1. 支援緊密協作的「多容器協同工作」

在實際的微服務開發中，很多功能並不需要寫進核心業務程式碼裡。例如：

• 收集主程式產生的 Log 並上傳到中央伺服器。
• 定期從遠端 Git 拉取最新設定檔給 Web Server 讀取。
• 負責網路通訊的 Proxy / Service Mesh 代理。

如果全部寫進同一個 Docker Image，會違反「單一職責原則」，讓 Image 變得臃腫且難以維護。Pod 允許我們把「主業務容器」與「輔助容器」分開打包成獨立的 Image，但部署時放在同一個 Pod 裡一起調度。

2. 共享網路命名空間（Shared Network Namespace）

同一個 Pod 內的所有容器，共享相同的 Network Namespace：

• 它們共享同一個 IP 位址與相同的 Port 空間。
• 容器之間可以透過 localhost:[PORT] 進行極高速、低延遲的本機通訊。
• 外部訪問這個 Pod 的 IP 時，會根據 Port 直接對應到 Pod 內的特定容器。

3. 共享儲存磁區（Shared Storage Volumes）

如果多個容器需要讀寫相同的檔案或暫存資料（例如：主容器寫入 Log 檔案，輔助容器負責讀取並壓縮），只要在 Pod 層級掛載一個 Volume，裡面的所有容器就能直接存取這個共享空間。

經典架構：Sidecar 模式（邊車模式）

在 Pod 包含多個容器的設計中，最知名的設計模式就是 Sidecar Pattern（像重型機車旁邊附掛的副駕駛座）：

• Main Container（主容器）：專注於核心業務邏輯（例如 Node.js 或 Java 寫的電商 API）。
• Sidecar Container（邊車容器）：負責輔助工作（例如執行 Fluentd 日誌收集器或 Envoy 代理）。

兩者生命週期完全綁定：一起被排程到同一個 Node、一起啟動、一起被銷毀。

Pod 的生命週期簡介

一個 Pod 從被建立到結束，通常會經歷以下幾種狀態（Phase）：

1. Pending：API Server 已經接受請求，但 Scheduler 還在尋找適合的 Node，或是正在下載容器 Image。
2. Running：Pod 已經綁定到 Node，且內部所有容器都已成功建立，至少有一個容器正在運行中。
3. Succeeded：Pod 內的所有容器已成功執行完畢並正常退出（常見於批次處理 Job）。
4. Failed：Pod 內至少有一個容器非正常退出（Exit Code 非 0）且終止。
5. CrashLoopBackOff：新手最常見的錯誤，代表容器啟動後立刻 Crash，K8s 正在嘗試重啟它但持續失敗。

本日小結

今天我們徹底解開了 Pod 的身世之謎：

• Pod 是 K8s 的最小調度單位。
• Pod 內部容器共享 IP、Port 與 Storage。
• 透過 Sidecar 模式，能夠在不破壞 Image 獨立性的前提下實現多容器協同工作。

了解了 Pod 的觀念後，明天我們不再用指令式操作，而是要學習生產環境最正統的做法：「【實作】第一個 Declarative 部署：撰寫 Pod YAML 檔並部署 Nginx」！