Container

事發：部署成功但服務掛了 一次例行的 Strapi 後端部署，Jenkins build 成功、Docker image 推上 ECR、kubectl set image 也順利執行。但 rollout 等了 300 秒後超時。 以下是整個部署流程，可以看到問題出在最後一步： 具體的錯誤訊息： error: timed out waiting for the condition Jenkins 回報「部署失敗，已自動回滾」。奇怪的是，build 每一步都成功了，問題出在 rollout 階段。 調查：Pod 起不來的真正原因 問題排查的過程如下，從 pod 狀態開始一路追到節點層級： 查看 pod 狀態，發現新 pod 卡在 Pending，舊 pod 卡在 Terminating： $ kubectl get pods NAME READY STATUS AGE strapi-stg-5896c67c-kvrn2 0/1 Pending 88s strapi-stg-69f7c958b7-kcbc7 1/1 Terminating 44h web-stg-7bb99cfb54-x8j99 0/1 Pending 88s 直覺反應是看 pod events： $ kubectl describe pod strapi-stg-5896c67c-kvrn2 Events: Warning FailedScheduling 0/2 nodes are available: 1 node(s) had untolerated taint {node.kubernetes.io/unreachable: } 1 node(s) didn't match Pod's node affinity/selector 兩個節點都不能用。 一個 unreachable，另一個 node selector 不符（env=stg vs env=prod）。 ...

前言：為什麼需要 Pod？ 在 Kubernetes 的世界裡，Pod 是一切的基礎。如果把 Kubernetes 比喻成一座城市，那麼 Pod 就是城市中的「最小住宅單位」。 但為什麼 Kubernetes 不直接管理容器（Container），而要多一層 Pod 的抽象？ 簡單回答：因為容器太小，Pod 剛剛好。 想像你要管理一座城市的住宅： 如果直接管理每個「房間」（容器）→ 太細碎，管理成本太高 如果直接管理整棟「大樓」（Node）→ 太粗糙，缺乏彈性 所以我們需要「住宅單位」（Pod）→ 大小適中，便於管理 本文將深入探討： Pod 的核心概念與設計哲學 Pod 的內部架構與運作機制 Pod 網路模型與通訊方式 Pod 生命週期與狀態管理 Pod 設計模式與最佳實踐 實戰範例與 YAML 配置 Pod 核心概念：容器的邏輯主機 什麼是 Pod？ 官方定義： Pod 是 Kubernetes 中最小的可部署計算單元，可以包含一個或多個容器，這些容器共享網路、儲存和其他資源。 生活化比喻： Pod 就像一個「邏輯主機」： 在傳統架構中，多個應用程式運行在同一台虛擬機上 在 Kubernetes 中，多個容器運行在同一個 Pod 上 Pod 提供了容器之間的「緊密耦合」環境 Pod 的三大核心特性 1. 共享網路命名空間 同一個 Pod 內的容器： ✅ 共享同一個 IP 位址 ✅ 可以透過 localhost 互相通訊 ✅ 但 Port 不能衝突（每個容器用不同 Port） 2. 共享儲存卷（Volume） ...