前十天講的是「為什麼」：agent 系統為什麼會撞上 container，資源為什麼要規劃。從今天開始進入「怎麼學」。

我不是 K8s 專家。這條路徑是我自己走過、回頭看覺得最不繞路的版本。重點不是學會 K8s 的全部，而是學到「夠讓一隻 agent bot 活在叢集裡，死了你看得出來為什麼」。

為什麼不從官方教學開始

官方文件很完整，但它的順序是給要成為 K8s 工程師的人看的。AI 工程師的需求不一樣：我手上已經有跑得起來的容器（Docker、compose），我要的是「把已經會的東西平移過去」，不是從 etcd 和 control plane 學起。

所以我的路徑是倒過來的：先讓東西動，再回頭補概念。

第 1 步：把 compose 玩到極限

如果你的 agent 現在還是一個 python main.py，先把它容器化，再用 docker compose 把它跟依賴（資料庫、向量庫、反向代理）組起來。這一步的價值是：你會親手寫下「這個服務需要哪些環境變數、開哪個 port、依賴誰」。這些答案就是搬家時的輸入：環境變數 → ConfigMap（機密的放 Secret）、port → Service、依賴誰 → 之後的 Pod／Service 設計。

我自己的 OpenAB bot 艦隊和 devstack（RAG 引擎 + qdrant + caddy）都是先在 compose 上跑穩的。compose 的天花板 Day 04 講過：一台機器、多個 session 疊加、記憶體壓力一來就全體遭殃。撞到那個天花板，你才會真的想學 K8s；在那之前，學了也留不住。

第 2 步：本機起一個真的叢集（k3s 或 minikube）

不要一開始就開雲端的 managed K8s。原因很實際：雲端叢集有帳單、有權限、有網路設定，每一項都會在你還不懂 Pod 是什麼的時候先絆倒你。

k3s 在一台 VM 上很快就能起來（Day 12 會實作），minikube 適合在筆電上。兩者目的一樣：給你一個可以隨便弄壞、隨便重裝的沙盒。

第 3 步：只學五個 kubectl 指令

我目前的理解是，日常八成的操作只靠這五個：

• kubectl get：看有什麼（pods、deployments、services）
• kubectl describe：看它為什麼是這個狀態
• kubectl logs：看它自己說了什麼
• kubectl apply -f：把 YAML 送進去
• kubectl delete：把東西清掉

其他的（exec、port-forward、rollout）遇到再查。先把這五個練到不用想，比背完整份 cheat sheet 有用。

第 4 步：部署你的第一隻 bot

拿 compose 裡最單純的那個服務（對我來說是一隻 OpenAB bot），把它翻成一個 Deployment + 一個 Secret + 一個 ConfigMap。Day 13 會做這件事。

這一步的重點不是 YAML 寫得多漂亮，而是你第一次感受到「宣告式」：你告訴叢集我要一個這樣的東西，而不是執行這個指令。

第 5 步：看它死掉，然後看懂為什麼

這是我認為最重要、也最常被跳過的一步。第一次部署幾乎一定會失敗：image 拉不到、環境變數沒給、port 寫錯、記憶體限制太小。這些失敗會以不同狀態出現（ImagePullBackOff、CreateContainerConfigError、CrashLoopBackOff），Day 14 專門講。

學會從 describe 和 logs 讀出原因，你就跨過了「會用」和「敢用」之間的那條線。

這條路徑刻意不包含的東西

Ingress、Helm、Operator、CRD、service mesh。不是不重要，是現在學太早。等你的 bot 在叢集裡活過一週、你開始覺得「手動改 YAML 好煩」的時候，Helm 自然會出現在你的搜尋紀錄裡。

明天動手：在一台 VM 上把 k3s 裝起來，含我踩過的雷。

今日一句話

先讓一隻 bot 在叢集裡活起來、死掉、再活起來；這比讀完整份文件更能讓你真的學會 K8s。

延伸閱讀

• Kubernetes 官方：kubectl 快速參考：kubectl Quick Reference
• k3s 官方：Quick-Start：Quick-Start Guide
• minikube 官方：Get Started：minikube start