POV：有人在會議裡問你「所以我們要不要上 K8s」，你發現自己答得出技術細節，卻答不出這個問題。
Week 4 的最後一天。前四天講了決策樹（Day 16）、一個決定不搬的真實案例（Day 17）、Spot VM 重開的實錄（Day 18）、成本結構（Day 19）。今天把它們收成一張 checklist。它不是「填完就有答案」的表，而是每一題都要有一個誠實的回答，答不出來的那題就是你還沒想清楚的地方。
1. 團隊大小：誰會半夜被叫起來？
一個人的 side project 跟三個人的小團隊，答案完全不同。一個人的時候，顧叢集的時間直接從寫 agent 的時間扣；managed K8s 把 control plane 外包了，但 YAML、網路、升級還是你的。我目前的判斷是：一個人先選單 VM 或 serverless 容器；有人專門顧 infra，才考慮 K8s。
2. 流量型態：一直在，還是被叫才動？
Day 16 的第一題、Day 19 的第一個陷阱、Day 21 還會再講一次。這題重要到我要問三遍，因為答錯它，計費模型和擴縮策略會全部跟著錯。Day 17 的 liaostudio 就是我自己先答錯的例子。
3. 服務數量與依賴：一個還是一群？
一隻 bot，compose 就好。bot 加 RAG 引擎加向量庫加反向代理，compose 撐得住但會擠，我的 devstack 就是這個狀態（Day 07）。要跨到第二台機器，才是 K8s 的主場。
4. GPU：要不要、要多久？
不需要就跳過。偶爾需要（推論、批次轉檔），像 Cloud Run GPU 這類按用量計費的比較合適，我的 Whisper backend 就是這樣用 L4（Day 08）。持續需要，才考慮 GPU node pool，但先看清楚常駐 GPU 的月費，以官方定價頁為準算過再決定。
5. 狀態：你的 agent 記得東西嗎？
in-memory 狀態、本地檔案、SQLite，這些在單 VM 上都合理，到 serverless 或多 replica 的 K8s 上都是問題。Day 17 評估 liaostudio 搬 Cloud Run 時，狀態放在哪裡就是卡點之一。要搬，先把狀態外部化；不想外部化，就先別搬。
6. 機器會不會被回收？
Spot / Preemptible 省錢，但 Day 18 的實錄提醒我：要先分清楚哪些東西宣告過、會自己回來（容器靠 restart policy、K8s 靠 Deployment），哪些沒宣告、要靠自己（我的 tmux 工作區）。K8s 對前者有結構性優勢，對後者沒有。
7. 合規：資料可以離開哪裡？
做客戶專案時，資料能不能出境、能不能上公有雲，是第一道閘門不是最後一道。這題如果答案是不能，決策樹直接砍掉一半，剩下自架 K8s 或地端 VM。細節不寫，但這題永遠先問。
8. 既有 credit：它什麼時候用完？
Day 19 講過我的原則：用 credit 的期間，架構要能在 credit 用完那天無痛降級。具體做法是每個放上雲端的東西，先想好「如果明天要搬回 Spot VM + compose，要動哪些檔案」。要動的檔案越多，代表我把架構綁得越死。
9. 你想解決的問題，搬了會解決嗎？
這是 Day 17 最大的教訓。我想解決的是「重開機自動跑起來」，systemd 已經解決了，Cloud Run 不會更好。把這題放最後，因為前八題答完，你常常會發現答案是不會。
我的用法不是逐題打勾，是找出答不出來的那題。答不出來的，就是你要先去搞清楚的事，通常是第 2 題（流量型態）或第 5 題（狀態）。這兩題搞清楚，其他的多半自己會有答案。
另一個用法是隔一段時間再填一次。我前陣子填的時候 liaostudio 是不搬，但表留著：哪天前端架構改了、狀態外部化了，答案可能就翻過來，不用從零再評一輪。
這一週沒有寫任何 YAML，全在講要不要。我認為順序是對的：Week 3 你已經會讓 bot 在 k3s 裡活著、死掉、再活過來，所以你有資格問值不值得；如果連沙盒都沒跑過就問，答案會是想像出來的。
明天進 GCP：先從 Cloud Run 開始，講它適合哪種 agent workload、跟 always-on bot 的矛盾在哪。
選型 checklist 的用法不是打勾，是找出你答不出來的那一題，那就是你該先去搞懂的地方。
iThome鐵人賽
看影片追技術