[前言]
寫這篇的那個早上，我的開發機又重開了一次。

那是台 GCP 上的 Spot VM，上面跑了 10 幾個 containers: Discord bot, LINE bot, 專案研究用的 RAG / MCP，當然也跑了十幾個 coding agent。
為了節省成本，選擇使用 Spot Instance，當然透過 Agent 討論，準備各種 Auto resume: 定時紀錄 Tmux and coding session，監控 VM 重開機訊號，提早儲存對話紀錄，也實驗過可以還原，之後也會公開這個小工具。

但實際上，重開之後有一部分服務沒預期般的回復（留到之後的篇章來探討）。這時才發現，我一直用單機思維，在管理一群本來就不該只依附在一台機器上的系統。

這就是這個系列的起點。今天先不談技術，把「這 30 天會寫什麼」和「你讀完能帶走什麼」講清楚。

為什麼是「被迫」

感謝所有前雇主跟客戶的機會，從產品上線跟專案開發的經驗理，我也算是個兼職 SRE，也曾經在雲地混合兼容的 MLOps 產品支援團隊理，學到 K8s 手工技巧 (kubectl 的肌肉記憶跟開車一樣終身難忘)。而在大家都能透過 AI 產文章，快速問到解答的這個時代，學 K8s 不是因為它炫，而是系統長到一個規模之後，不學就得天天被同一批問題折磨：

• 多個 agent session 同時跑，互搶記憶體，swap 塞滿，整台機器卡住（Day 04）
• 一個閒置兩天沒人碰的 dev container，默默吃掉 1.25 GiB，直到手動清查才發現（Day 04）
• 推論引擎的記憶體上限到底該設多少？設錯了不是 OOM 就是浪費（Day 07、Day 09）
• Spot VM 回收重開後，哪些服務該自動回來、哪些不該？是否會有個準則（Day 18）

也許即時修修補補 docker compose 都能「暫時」壓下來，但每次的解法都變成我腦袋裡的隱性知識，散在零碎的 script 裡；換一個環境就得重來。

K8s 不是系統規模畫的唯一解，此時此刻，還在懷疑目前自己的環境，客戶的環境是否真的需要它。但藉著把「一個 agent 需要多少資源、掛了要不要重啟、對外怎麼連」這些事，寫成明確的宣告式設定，身為工程師，就該好好的回顧將這些東西記錄下來。

這 30 天會寫什麼

整個系列分六週，每週回答一個問題：

第一週｜為什麼要碰：從 agent 的本質是一堆程式講起。當上線的 bot 從一隻成長到一個隊伍之後，怎麼會發散到失控、另外 container 到底替 AI 工程師解決了什麼、compose 為什麼撐不住目前需求。最後，再次複習 Pod / Deployment / Service 三個基本觀念。

第二週｜資源怎麼想：long-running bot、burst build、GPU 推論是三種完全不同的工作負載，不能一種部署法打天下。常見的 RAG 解決方案底下，memory cap 怎麼定；我從自己 Vibe 了 Whisper GPU backend 學到的事；從「記憶體壓力事件」，回頭思考 requests / limits / OOMKilled 的調整與心得；training 跟 inference 為什麼幾乎不該共用一個 Cluster。

第三週｜怎麼學：這系列又開始重頭複習時，我所列出的學習路徑，Hands-on：在一台 VM 上裝 k3s/microk8s/kind 之類、搬遷 bot (from docker-compose)、看 log 和 kubectl指令。這週為實作篇。

第四週｜怎麼選：一樣先是以「你的問題真的需要 K8s 嗎」畫一張決策樹；實際情境下，評估 Serverless (Cloud Run etc.), Cloud Provioder K8s (GKE, AKS) 的選型思路；Spot 的代價；選型心得與我之後遇到問題時拆解的 checklist。

第五、六週｜上雲：同一個 agent workload 分別部署到 Cloud Run、GKE Autopilot、AKS，YAML 對照著看；GPU 在 GCP 上的兩條路；最後一張 GKE / Cloud Run / AKS / ACA 的對照總表，如果時間允許，AWS 也會加進對照表。

每篇會標明類型：敘事（概念與心得）、案例（以我專案裡的真實事件為骨幹）、實作（YAML 與指令）。每篇結尾固定有「今日一句話」和「延伸閱讀」。

讀完之後可以帶走什麼

如果你跟完 30 天，我希望你手上多了這幾樣東西：

1. 決策思路地圖：「agent 真的要上 K8s?」。
2. 一種翻譯能力：「bot 實際運作時會遇到的狀況，像是 cpu/memory 預估、要不要對外」 -> 轉成 Container 對應的技術觀念。
3. 最小可自行驗證的環境：用 k3s/kind/microk8s 跑起 bot，並且知道怎麼排查問題。
4. 跨雲端對照表：同一個 workload 在 GKE / Cloud Run / AKS / ACA 上的差異。
5. 最小 SRE 自我小筆記：升級、備份、preemption 演練、成本告警。

你不會帶走的：K8s 內部原理、etcd 與 scheduler 的細節、企業級的治理與身份驗證架構。

這個系列不是什麼

• 不是 K8s 教學。 試著只講需要的觀念，但是不從原理一直講太多基礎。
• 不是企業架構規劃文。 身份驗證、OAuth。

目標讀者：會寫 AI agent、懂 TypeScript/Python/Rust 與 Docker 基礎，但沒碰過或剛碰 K8s 的工程師。 如果你是資深 SRE，這個系列可能太淺；如果你跟我一樣，是被自家 agent 系統一步步推到 K8s 門口，思考真的需要這玩意的人，我試著帶到門口讓各位思考與選擇。

明天從最核心的那件事講起：為什麼 agent 是「一堆程式」。