三十天，從 kubeadm init 敲下的第一行指令，到最後一天完成叢集版本升級——我們一步步建起了一套完整的 Kubernetes 知識體系。
回頭看，這趟旅程大致可以拆成 六大主題，每一段都有它要回答的核心問題。
核心問題：怎麼把叢集跑起來，讓應用能自動伸縮？
| Day | 主題 | 學到的事 |
|---|---|---|
| Day 01｜使用 kubeadm 建立 Kubernetes 叢集 | kubeadm 建立叢集 | 從零搭建 1 Control Plane + 2 Worker 的實驗環境 |
| Day 02｜Pod 與 Deployment — 從「一次性容器」到「自動維運」 | Pod 與 Deployment | 理解 Kubernetes 最基本的工作負載單位，以及 Deployment 如何維持副本與更新應用 |
| Day 03｜HPA — 讓 Kubernetes 自己決定要跑幾個 Pod | HPA 水平自動擴縮 | 讓 Kubernetes 根據負載自動調整 Pod 數量 |
這三天奠定了所有後續實驗的基礎。沒有叢集，一切都是紙上談兵。
核心問題：流量怎麼從外部進來，又怎麼正確地找到 Pod？
| Day | 主題 | 學到的事 |
|---|---|---|
| Day 04｜Service — 為 Pod 提供穩定的存取入口 | Service | ClusterIP、NodePort、LoadBalancer 三種暴露方式 |
| Day 05｜Service 背後的秘密 — kube-proxy 與流量轉發機制 | kube-proxy | iptables / nftables / IPVS 三種流量轉發模式的差異 |
| Day 06｜Ingress — 一個入口，接管所有微服務流量 | Ingress | 用一個入口統一管理 HTTP / HTTPS 路由 |
這段的重點是理解 「Pod IP 可能會變，Service 才是穩定的存取入口」，以及 kube-proxy 在背後負責的流量轉發機制。
核心問題：設定怎麼管？資料怎麼存？有狀態的應用怎麼跑？
| Day | 主題 | 學到的事 |
|---|---|---|
| Day 07｜ConfigMap — 把設定從程式碼中抽離 | ConfigMap | 將設定與程式碼分離，讓不同環境更容易切換 |
| Day 08｜別再把密碼寫進 YAML！Secret 的正確打開方式 | Secret | 管理密碼、Token、憑證等敏感資料 |
| Day 09｜Kubernetes 如何讓「無狀態 Pod」支援「有狀態資料」 | PV / PVC | 讓 Pod 掛載可持久保存的儲存空間 |
| Day 10｜StorageClass — Kubernetes 如何自動建立儲存？ | StorageClass | 透過 Dynamic Provisioning 自動建立儲存資源 |
| Day 11｜StatefulSet — 讓有狀態應用真正穩定運行 | StatefulSet | 提供穩定身份、持久化儲存與有序部署能力 |
從 ConfigMap 到 StatefulSet，這五天回答了一個關鍵問題：Kubernetes 不只可以跑無狀態應用，也能管理需要持久資料與穩定身份的工作負載。
核心問題：Pod 要跑在哪裡？怎麼精準控制排程行為？
| Day | 主題 | 學到的事 |
|---|---|---|
| Day 12｜Kubernetes Scheduler 與資源管理 — Pod 到底會被排到哪個 Node？ | Scheduler 與資源管理 | 理解 requests / limits 與排程決策之間的關係 |
| Day 13｜Node Affinity 與 Taints & Tolerations — 精準控制 Pod 的排程位置 | Node Affinity & Taints | 控制 Pod 想去哪個 Node，以及哪些 Pod 能進入特定 Node |
| Day 14｜Pod Affinity 與 Anti-Affinity — 控制 Pod 之間的排程關係 | Pod Affinity / Anti-Affinity | 控制不同 Pod 之間的共存與隔離 |
| Day 15｜topologySpreadConstraints — 更優雅的 Pod 分散機制 | topologySpreadConstraints | 將 Pod 更平均地分散到不同拓撲域 |
| Day 16｜PriorityClass 與 Preemption — Pod 的優先級與搶佔機制 | PriorityClass & Preemption | 資源不足時控制哪些 Pod 擁有更高排程優先權 |
| Day 17｜Init Container — Pod 啟動前的初始化機制 | Init Container | 在主要 Container 啟動前完成必要的前置作業 |
| Day 18｜Sidecar Container — Pod 的最佳副手 | Sidecar Container | 讓輔助 Container 與主要應用共同運作 |
這七天是整個系列中排程觀念最集中的一段。
排程不只是 Kubernetes 自己的事，理解這些機制後，才能更進一步設計高可用、資源隔離與更合理的工作負載分布。
核心問題：怎麼管理資源邊界，又怎麼把一堆 YAML 變成可重複使用的套件？
| Day | 主題 | 學到的事 |
|---|---|---|
| Day 19｜Namespace — Kubernetes 的資源隔離與多租戶管理 | Namespace | 建立資源邏輯邊界，作為權限與多租戶管理的基礎 |
| Day 20｜Helm — Kubernetes 的套件管理工具 | Helm 入門 | 認識 Chart、Release、Repository 三大核心概念 |
| Day 21｜打造你的第一個 Helm Chart | 打造第一個 Chart | 從零建立一個可以安裝與升級的 Helm Chart |
Day 22｜Helm 進階模板與 _helpers.tpl — 讓 Chart 更靈活、更好維護 |
進階模板 & _helpers.tpl | 使用 include、nindent、with 等功能提升 Chart 可維護性 |
| Day 23｜Helm Repository 與 Chart 依賴管理 | Repository & 依賴管理 | 管理 Chart 的分享、版本與 Dependency |
Helm 是從「手動管理 YAML」走向「可重複、可版本化部署」的重要一步。
透過 Namespace 與 Helm，我們也開始從單純部署應用，進一步思考資源邊界與部署流程的工程化管理。
核心問題：怎麼讓叢集安全、可擴展、可維護？
| Day | 主題 | 學到的事 |
|---|---|---|
| Day 24｜RBAC — Kubernetes 的角色權限控制 | RBAC | 控制誰可以操作哪些 Kubernetes 資源 |
| Day 25｜NetworkPolicy — Kubernetes 的網路策略與零信任隔離 | NetworkPolicy | 實作 Pod 層級的網路隔離，以及 Zero Trust 常見的網路控制方式 |
| Day 26｜Gateway API — Kubernetes 的下一代流量入口管理 | Gateway API | 使用更標準化、角色分離的方式管理流量入口與路由 |
| Day 27｜CRD 與 Operator — 擴展 Kubernetes API，打造自訂資源與控制器 | CRD & Operator | 自訂 Kubernetes Resource，並透過 Controller 實作自動化邏輯 |
| Day 28｜cert-manager — 自動申請、管理與續約 Kubernetes TLS 憑證 | cert-manager | 自動申請、儲存與續約 TLS 憑證 |
| Day 29｜etcd — Kubernetes 的狀態資料核心 | etcd | 理解 Kubernetes 狀態儲存、Raft、Snapshot 備份與還原 |
| Day 30｜Kubernetes 叢集升級 — 使用 kubeadm 從 v1.34 升到 v1.35 | 叢集升級 | 使用 kubeadm 完成 Control Plane 與 Worker Node 的版本升級 |
最後這七天把視角從「使用 Kubernetes」拉高到「治理與擴展 Kubernetes」。
一個穩定的叢集不只需要會部署，還需要懂權限、網路、安全、自動化、資料保護與版本維護。
老實說，剛開始動筆的時候心裡想的是：「只寫 Kubernetes，三十篇到底要怎麼生出來？」結果越寫越發現，三十篇根本寫不完——每個主題一展開就是一整篇，還有好多細節想補。
更有趣的是，有些明明很基礎、很重要的東西，像是 Namespace，竟然一路寫到後半段才驚覺：「等等，我居然還沒寫到！」只好趕緊塞進去。計畫永遠趕不上變化。
其實這個系列有不少內容，是從我今年 2 月準備 CKA 時一路累積下來的。當時為了考試自己搭叢集、查文件、做實驗，也留下了很多筆記，後來才慢慢把它們整理成這三十天的內容。
不過 Kubernetes 和周邊生態更新得很快，從 2 月到現在，有些版本、API 狀態、安裝方式或官方建議已經有所變化。因此這系列裡部分實作會保留我當時真正做過的版本與截圖，同時盡量補上現在需要注意的差異。
我覺得比起記住某一條指令，更重要的還是理解它背後在做什麼。版本會變、工具會更新，但只要核心概念有建立起來，之後遇到新的版本也比較知道該從哪裡查、怎麼判斷。
感謝每一位讀到這裡的你。三十天的內容不短，能一路看到最後，甚至真的跟著把環境搭起來、把指令跑過一遍，都很不容易。
這三十天對我自己來說，也算是重新把準備 CKA 時學過的東西再整理、驗證一次。很多原本以為已經懂的內容，真的開始寫之後才發現還有不少細節值得重新確認。
最後也提醒一下，Kubernetes 的版本與生態一直在演進，實際使用在正式環境前，還是要記得確認當下版本的官方文件。
謝謝你陪我走完這三十天。
iThome鐵人賽
看影片追技術