上一篇 NetworkPolicy 把 Cluster 內部流量的邊界劃清楚了， 但承載敏感資料的 Pod 真正怕的不只是流量被偷窺——還怕重啟那一刻資料就消失。 Pod 的本地檔案隨 Pod 終止而消滅，誰來保證資料庫的儲存即使 Pod 重建仍能掛回原本那一塊？ 本篇拆解 PV／PVC／StorageClass 三件套如何把宣告轉成雲端實體 Volume， 以及 CSI external-provisioner 在背後如何把 PVC 翻譯成雲端 API 呼叫。

前幾篇把流量如何從外部接進 Cluster 說清楚了； 進來之後，任意兩個不相關的 Pod 直接 curl 對方， 會通——Cluster 內預設沒有邊界，Pod 間流量暢通無阻，任一 Pod 被入侵，攻擊者就能橫向抵達任意服務。 本篇拆解 NetworkPolicy 如何把這個預設從 default-allow 翻成 default-deny， 以及為什麼宣告生效要靠 CNI 在 Node 上實際攔截封包。

Ingress 把多個服務收攏在同一台對外 LB，靠 hostname 與 path 分流——但進階能力全靠廠商各自定義的 annotation，換 Ingress Controller 就要整份重寫； 而且所有設定共用同一種物件型別，RBAC 無法區分「誰能改 TLS 憑證」和「誰能加一條路由規則」。 Gateway API 從這兩個限制出發，把 Ingress 的單一資源拆成 GatewayClass、Gateway、HTTPRoute、ReferenceGrant、BackendTLSPolicy 五個分工物件， 讓職責邊界從 annotation 浮上 spec、讓各角色透過 RBAC 各管各的。

Service 解決了「封包怎麼送到 Pod」，但 LoadBalancer 一個服務一台雲端 LB 的計價方式，讓任何擁有十個微服務的團隊都會在月底看到帳單時冷汗直流。 還有一件事沒解決：能不能只租一台對外入口，讓多個服務共用同一個 IP， 靠 hostname 或 path 做 L7 分流？ 這就是 Ingress 與 IngressClass 要回答的——它們本身只是 etcd 中的宣告， 真正聽流量的是另一個獨立的 Pod，叫 Ingress Controller。 這篇拆解這層抽象，並說明為什麼 Kubernetes 已將 Ingress 標記為 feature-frozen（不再新增功能）， 並推薦新案改用 Gateway API。

EndpointSlice 即時記錄了「哪些 Pod 還活著」、CoreDNS 把名字翻譯成 IP—— 但這個 IP 沒有任何網路裝置真正持有：沒有任何網卡綁定它，封包卻能送到後端 Pod。 封包怎麼走？誰在做 NAT？ 這篇拆解 Service 的三種 type、kube-proxy 的工作原理、以及為什麼只有 LoadBalancer 會主動向雲端索要實體資源——其餘 type 都只是 etcd 中一行宣告。

Deployment 的 Pod 每次重建 IP 都不同；StatefulSet 的 Pod 有固定的身份與名稱， 但名字本身不等於可連線的位址——名字到 IP 的轉換，仍然需要有人負責。 Cluster 內的 Pod 之間究竟怎麼溝通？請求是怎麼被解析的、流量是怎麼傳遞的？ 答案不在 Service 本身，而在它背後兩個沉默的元件： EndpointSlice 負責即時記錄「哪些 Pod 還活著且能接收流量」， CoreDNS 負責把名字翻譯成可連線的位址。 這篇拆解服務發現的資料來源層，說明為什麼 Service 的所有行為都必須建立在這兩個元件之上。

Deployment 管副本與版本切換、StatefulSet 管身份與順序， 但每個 Pod 跑起來之後讀的設定值與憑證從哪來？硬塞進 image 會綁死環境， 寫死在 spec.template 又會把資料庫密碼洩漏到 git。 這篇拆解 ConfigMap 與 Secret 的職責邊界、Spec 語意與更新傳播機制， 並說明為什麼它們和 Deployment、StatefulSet 同屬「純宣告」—— 不直接觸發任何雲端資源，卻是讓 image 能跨環境重用的最後一塊拼圖。

DaemonSet 補完了「每節點一份、永遠在跑」的最後一塊拼圖， 但有一整類任務剛好相反——schema migration、夜間批次報表、ML 訓練： 這類任務的特徵是「一次性、有終止狀態」——按時觸發、跑完即退場，不是「保持在跑」。 Job 與 CronJob 是 Kubernetes 給這類任務的宣告式介面： Job 負責調度 Pod、追蹤成功與失敗，在達標或耗盡重試時給出明確的終止狀態； CronJob 在 Job 之上加一個時間維度，把單次任務變成週期任務。

前一篇的 HPA 把 `replicas` 從寫死的常數變成依指標反推出來的動態值， 但這條路線假設「副本數可以自由伸縮」。但有一類 workload 問的不是這個—— 日誌收集器、節點監控，這些角色不在乎幾份，只在乎「每台 Node 上都得有一個」。 這篇拆解 DaemonSet 如何把「每節點一份」這個需求轉化為宣告， 說明它與 Deployment / StatefulSet 一樣屬於「純宣告」—— 本身不消耗任何雲端資源，但它的副本數卻是需與 Node 數量同步，這個特性會反過來 影響 Node 規格的選擇。

HPA 把 Deployment 與 StatefulSet 寫死的 `replicas` 從常數變成動態值—— 依 CPU、記憶體或自訂指標推導出當下應跑的副本數，再自動回寫 Workload。 這篇拆解 HPA 如何讀指標、套公式、控制擴縮節奏，以及 Metrics Server 在這條 pipeline 上扮演的角色。