我們已經碰過不少 Kubernetes 物件與指令。
最後一天把既有零件串起來：工作負載如何被宣告、排程、連線、更新、擴縮，以及如何查問題。
這張合照象徵三十天課程裡，我們一起認識的 Kubernetes 世界。
島上的角色代表不同工作：有人提交設定、有人安排工作、有人維持服務運作，也有人觀察狀態與處理問題。
① 提交需求：使用者透過 kubectl 將 YAML 提交至 API Server。
② 狀態調節：控制器透過 API Server 觀察物件狀態並建立或更新資源。
③ 節點調度：Scheduler 讀取未排程的 Pod，選定合適 Node 並透過 API Server 寫入 binding。
④ 容器執行：Node 上的 kubelet 讀取 Pod 規格，呼叫容器執行階段並回報狀態。
⑤ 回饋迴圈：使用者透過 kubectl 查詢狀態，必要時修改 YAML 再次提交。
我們用 Kind 建立了一座本機叢集，並在上面部署雙層架構的服務。
① Web 層：Nginx，同時跑 3 個 Pod
replicas: 3 並管理版本② 資料庫層：Postgres
③ 穩定性與擴縮：讓 Web 層自己顧好自己
成果：整套系統以十個 YAML 檔描述，可以用相同指令重建。
限制：這仍是教學環境。 還缺少跨機器高可用、正式儲存、RBAC、監控、告警與備份。
不過它已經把 Kubernetes 最重要的控制迴圈串了起來：提交期望狀態、由控制器持續調和，再透過觀測結果修正設定。
Q1：Pod 起不來怎麼查？
先用 get 看狀態，再用 describe 看物件細節與 Events，最後視容器狀態用 logs 檢查程式輸出。
關鍵區分是：Events 是叢集元件針對物件所發出的事件，logs 是容器標準輸出與錯誤輸出；容器尚未啟動時，通常還沒有該容器的應用程式 logs。
ImagePullBackOff 先看 Events；CrashLoopBackOff 可用 logs --previous 查看前一個已終止容器的日誌；Pending 則檢查排程條件與 FailedScheduling Events。（Day 12）
Q2：Service 三種型態差在哪？
它們是 Service 的不同 type。NodePort 會在 ClusterIP Service 的基礎上配置節點連接埠；LoadBalancer 通常也會配置 ClusterIP，並通常配置 NodePort，但可透過 allocateLoadBalancerNodePorts: false 關閉 NodePort，前提是負載平衡器實作不依賴 NodePort。
原則是只暴露實際需要的範圍。
LoadBalancer Service 需要叢集中有對應的負載平衡器實作；在沒有該實作的本機環境中，EXTERNAL-IP 可能一直顯示 <pending>。（Day 15）
Q3：Deployment 怎麼做到零停機？
Deployment 會為不同版本建立 ReplicaSet。
滾動更新時，新版本逐步增加、舊版本逐步減少；新的 Pod 未 Ready 時，可用副本數可能不足，更新會無法繼續前進。控制器會依 progressDeadlineSeconds 判定更新是否停滯並回報 ProgressDeadlineExceeded，但不會因此自動回滾。maxUnavailable 控制更新期間最多可少多少可用副本，maxSurge 控制最多可額外建立多少副本。
舊 ReplicaSet 通常會在保留的修訂範圍內留下紀錄，rollout undo 可將 Deployment 回復到先前修訂；若舊映像不在 Node 快取中，仍須重新拉取。滾動更新設定提供更新策略，但不保證所有應用在任何故障情況下都零停機。（Day 10、11）
Q4：PV 跟 PVC 是什麼關係？
PV 代表叢集中的儲存資源，PVC 是使用者提出的儲存需求，Pod 透過 PVC 使用儲存。
這層抽象讓工作負載不必綁死 EBS、NFS 等底層實作。
StorageClass 描述儲存類別及其供應方式；動態供應時由對應 provisioner 建立底層 volume。PVC 釋放後，PV 的回收策略（例如 Delete 或 Retain）會影響 PV 和底層儲存的後續處理，應依資料保留需求設定。（Day 22）
Q5：三種探針（Probe）差在哪？
Liveness 探針失敗達門檻時，kubelet 會終止該容器，後續是否重啟依 Pod 的 restartPolicy；Readiness 決定 Pod 是否可接收 Service 流量；Startup 成功前，kubelet 暫緩執行該容器的 Liveness 與 Readiness 探針。
Liveness 過於敏感會造成反覆重啟；依賴的外部服務（例如資料庫）出問題時，應交給 Readiness 處理，不要放進 Liveness，避免容器因外部故障被反覆重啟。
若服務暫時無法處理請求，可透過 Readiness 先停止導入流量。（Day 24）
這五個問題都指向同一件事：不要只記物件定義，要理解控制器在什麼條件下採取什麼動作，以及該從哪一層觀察結果。
接下來可以依這個順序補上五項能力：
Helm：YAML 模板與套件管理。
RBAC 與 ServiceAccount：管理誰能對櫃台執行哪些操作。
Operator：把領域維運知識寫成控制器。
Service Mesh：處理服務間的加密、重試、流量切分與觀測。
GitOps：讓 Git 成為設定來源，由系統持續比對 Git 與叢集現況。
五個都不急。先把這三十天的物件組合成一套能部署、更新、觀測與復原的系統，再逐步補上缺少的能力。
最後，還記得 Day 1 那個在三台機器之間搬容器、用 Excel 記哪個服務在哪台的人嗎？
三十天後，那張 Excel 變成了十個 YAML 檔；叢集狀態則由記憶樹（etcd）保存。
恭喜你獲得這個技能
你可以 「使用 Kind 建立 Kubernetes 叢集，部署 Nginx/Postgres 雙層服務，完成 Service、Ingress、PVC、Probe 與 HPA 設定。」
你不再記哪台跑什麼，島替你記。
Day 1：一台機器管不動了，為什麼會有 K8s？
Day 2：K8s 5分鐘登島，用 Kind 蓋出你的第一座雲之島 Cluster
Day 3：K8s 雲之島全景圖， 一張圖說完 Cluster、Node、Pod
Day 4：K8s 燈塔村在忙什麼？Control Plane 中的核心角色 - API Server、etcd、Scheduler、Controller Manager
Day 5：K8s 你手上的哨子，kubectl 最常用的 8 個指令
Day 6：k8s 的泡泡 Pod，為什麼容器要多包一層？
Day 7：K8s 手寫第一個 Pod YAML，把服務放進泡泡 Pod
Day 8：彩色貼紙 Label，K8s 到底怎麼認出誰是誰？
Day 9：K8s Pod 破了誰來補？ 會數泡泡 Pod 的貓頭鷹 ReplicaSet
Day 10：K8s Deployment 怎麼滾動更新？部署管家的版本卷軸
Day 11：K8s 零停機實戰，更新到一半後悔就一鍵 rollback
Day 12：K8s 泡泡 Pod 起不來怎麼辦，describe、logs、events 三件套
Day 13：K8s 圍籬 Namespace，把不同團隊的樹節點分開種
Day 14：K8s 重要角色登場，泡泡 Pod 會破，柱子 Service 不會
Day 15：k8s 的 ClusterIP、NodePort、LoadBalancer 差在哪？
Day 16：K8s 大門地圖看板 Ingress，一個網域分流到多個服務
Day 17：K8s 網路實戰，從瀏覽器打到 hello service
Day 18：K8s 中場總覽，一張圖追完封包從大門到 Container 的旅程
Day 19：K8s 掛在泡泡 Pod 外的便條本 ConfigMap
Day 20：K8s 上鎖的小盒子 Secret，它其實沒那麼安全
Day 21：K8s 泡泡 Pod 裡的 emptyDir，為什麼重啟之後資料就不見了
Day 22：K8s Cluster 島上的倉庫與借用單 PV 與 PVC
Day 23：K8s 資料實戰，幫 hello service 接上一個資料庫
Day 24：K8s 三種探針 Probe，存活檢查探針鈴 Liveness Probe 、就緒探針小旗子 Readiness Probe、啟動探針 Startup Probe
Day 25：Request 與 Limit，Resource Request、Resource Limit 資源需求與資源上限
Day 26：自動調節旋鈕 HPA，碼頭排隊了就調高期望數量
Day 27：K8s 編號泡泡管理員 StatefulSet，什麼時候需要固定身分
Day 28：K8s 一次認識三個管理者，守樹隊長 DaemonSet 、一次性任務委託單 Job 、定時任務鐘 CronJob
Day 29：K8s Cluster 雲之島全圖，一張圖看懂 Kubernetes 怎麼運作
Day 30：K8s 總結，串起 Kubernetes 的核心機制
如果你對本系列文有興趣，也喜歡這個用 K8s 建構的雲之島世界
歡迎來玩我的小遊戲：K8s 雲之島冒險
iThome鐵人賽
看影片追技術