POV：三十天前你打開 Day 01，看到一個 AI 工程師說他是「被迫」學 K8s 的；三十天後你想知道，他到底學了多少、又決定先不學哪些。

寫完了。Day 01 那天早上，我的開發機又重開了一次，我在那篇說這個系列不是 K8s 教科書，是一個主業寫 agent 的人的學習日記。今天把三十天濃縮成一頁，給跟我一樣主業是 agent、不是叢集的同行。

一頁式答案：AI 工程師該懂多少 K8s

懂到能做決策就好，不用懂到能維運整個叢集。 具體是五件事：

1. 分得清自己的 workload 是哪一種（Day 06、Day 21）：always-on 的 bot、request-driven 的 API、偶發的 GPU 推論、長時間的 training，資源性格不同，部署法就不同。這一題分不清，後面全是瞎猜。
2. 會用 requests / limits 描述自己要多少（Day 07、Day 09、Day 24）：這是 K8s 詞彙裡跟 AI 工程師最直接相關的一句話。它影響排程、影響 Node 壓力大時誰先被請走，在 Autopilot 上它就是帳單。
3. 答得出「你真的需要 K8s 嗎」（Day 16、Day 17）：我自己的答案目前是「還不需要」。always-on bot 留在 VM 加 Docker 上，request-driven 的 Whisper backend 放 Cloud Run GPU，liaostudio 評估完決定暫不搬。這不是逃避，是把 K8s 留給真的需要它的那天。
4. 知道換雲要重學哪三樣（Day 26、Day 27、Day 28）：Deployment、Service 是跨雲的語言；registry 授權、ingress 實作、identity 是各家的方言。Day 27 逐行對照 GKE 與 AKS 的 YAML，Deployment 與 Service 只差 image 路徑，Ingress 多一行 class。
5. 故意讓它死一次（Day 18、Day 29）：不管用不用 K8s，還原機制沒被真的故障驗證過，就很難知道它是真的還是裝飾。這三十天裡我的開發機重開了一次、有一部分 session 沒回來，那是整個系列最值錢的一課，而且免費。

其他的，node pool 細節、底層網路、operator、service mesh，撞到再學。先把 agent 做好，K8s 是為它服務的，不要反過來。

系列索引

Day 01–22 是已經定稿的標題，Day 23–29 照各篇 review 中的標題，發表時可能微調。

Week 1｜Agent 為什麼會撞上 K8s：Day 01 我為什麼（被迫）開始學 K8s ／ Day 02 Agent 不是一個程式，是一堆程式 ／ Day 03 Container 對 AI 工程師到底解決了什麼 ／ Day 04 為什麼 docker compose 還是不夠：當環境 swap 見底的時候 ／ Day 05 K8s 三個心智模型，用 bot 艦隊講一遍

Week 2｜AI infra 與 K8s：Day 06 Agent 系統的三種工作負載 ／ Day 07 RAG 引擎 + 向量庫 + 反向代理：memory cap 怎麼定 ／ Day 08 GPU 不是「有就好」 ／ Day 09 requests / limits、OOMKilled、swap ／ Day 10 training 跟 inference 為什麼幾乎不該共用一個叢集

Week 3｜沒碰過 K8s 的 AI 工程師怎麼起步：Day 11 我建議的 5 步學習路徑 ／ Day 12 在一台 VM 上裝 k3s ／ Day 13 把一隻 bot 從 compose 搬到 k3s ／ Day 14 它為什麼一直 CrashLoopBackOff ／ Day 15 觀測最小可行組合

Week 4｜該怎麼選雲端 K8s 部署 AI app：Day 16 先問「你真的需要 K8s 嗎」 ／ Day 17 我的真實決策：評估 Cloud Run 後決定「暫不搬」 ／ Day 18 Spot / Preemptible 的代價 ／ Day 19 成本模型 ／ Day 20 選型 checklist

Week 5｜GCP：GKE vs Cloud Run：Day 21 Cloud Run 適合哪種 agent workload ／ Day 22 GKE Autopilot vs Standard ／ Day 23 把一個 agent API 部署到 Cloud Run ／ Day 24 同一個 workload 上 GKE Autopilot ／ Day 25 GPU on GCP

Week 6｜Azure AKS 對照與收尾：Day 26 AKS 對 GKE：概念對照表 ／ Day 27 同一個 agent workload 上 AKS 最小集 ／ Day 28 GCP 與 Azure 對照總表 ／ Day 29 維運日常：AI 工程師的最小 SRE 清單 ／ Day 30 本篇

我沒寫、但你可能想知道的事

這個系列刻意避開了幾件事，老實列出來：

• 身分驗證與治理（OAuth、JWT、agent 的權限邊界）：這是另一個獨立的大題目，同組別另一個系列已經深耕，我選擇不碰。
• K8s 內部原理（scheduler、etcd、CNI）：AI 工程師要用好它，不需要先知道它怎麼蓋的。
• 具體價格與配額：一律寫「以官方定價頁為準」附連結，不抄數字，因為價格會變，我不想留一張過期的表。
• 實作篇沒有實跑：Day 12、13、15、23、24、27 的指令與 YAML 是照官方文件整理的最小集，front matter 老實標了 verified: false。這不是藉口，是提醒你不要直接複製貼上。

下一步，給我自己

1. 把 Day 13 那份 YAML 真的在 k3s 上跑起來，把 verified: false 改掉，然後放著跑一段時間，看它跟 VM 上 Docker 版的維運體驗差在哪。
2. 第二個 GPU workload 出現時，回頭用 Day 25 那張決策表再走一次，不提前為想像中的未來開 node pool。
3. Day 29 的「故意殺一次」排進固定行程。9/7 那次重開換來的教訓，我不想等下一次意外才複習。

謝謝你讀到這裡。三十天前我不確定一個「淺但誠實」的 K8s 系列有沒有價值；寫完之後我確定了：對 AI 工程師來說，知道自己暫時不需要知道什麼，跟知道該知道什麼一樣重要。

今日一句話

AI 工程師該懂的 K8s 只有五件事：分得清 workload、寫得出 requests / limits、答得出需不需要、知道換雲要重學哪三樣、敢故意讓它死一次；其他的，撞到再學。

延伸閱讀

• 想從概念開始補的話，官方的 Overview 是最好的起點：Overview | Kubernetes
• 之後撞到再學時要翻的地方：Kubernetes Documentation
• GCP 官方對「該用 GKE 還是 Cloud Run」的說法，跟 Day 28 那張表對照著看：GKE and Cloud Run