POV：bot 終於在 k3s 裡 Running 了，你習慣性敲 docker stats，卻發現叢集裡的東西 Docker 一個都看不到，你連它現在吃多少記憶體都說不出來。

Week 3 的最後一天。Day 13 把一隻 bot 搬進 k3s、Day 14 學會它掛掉時怎麼看，今天要回答的是：它活著的時候，我怎麼知道它活得好不好？compose 時代我靠 docker stats 加 docker logs -f；到了 K8s，對應的工具是什麼、差在哪，今天把最小的一套整理出來。

跟 Day 12 到 14 一樣，這篇的指令是照官方文件整理的，還沒在乾淨的叢集上從頭重跑過一次，front matter 標了 verified: false；k3s 上的實際行為請以官方文件為準。

資源用量：kubectl top

kubectl top nodes
kubectl top pods -l app=my-first-bot --containers

這是 docker stats 最直接的對應，但有兩個差別要先知道。

第一，kubectl top 自己不量任何東西，它是去問叢集裡的 metrics-server；沒裝的話會直接報錯。k3s 把 metrics-server 列在預設打包的元件裡（可以用 --disable metrics-server 關掉），所以 Day 12 裝的那台通常直接能用；自己用 kubeadm 或 minikube 起的叢集，要另外裝或開 addon。

第二，它給的是一個快照，不像 docker stats 會一直刷。想盯著看要 watch kubectl top pods，想看趨勢就要接真正的 metrics 系統，那已經超過今天的最小組合。

我為什麼在意這個：Day 04 那次記憶體壓力，我是用 docker stats 加 free -h 人工對照，才找到一個閒置 45 小時、吃了 1.25 GiB 的 dev 容器。到 K8s，kubectl top pods --containers 一行就能把每個容器的實際用量列出來，跟 Day 09 寫進 YAML 的 requests / limits 對照，哪個容器貼著 limit 走，比較容易看出來。

Log：從一個容器到一群 Pod

kubectl logs -l app=my-first-bot --tail=100 -f
kubectl logs -l app=my-first-bot --all-containers --since=10m
kubectl logs <pod-name> --previous

docker logs 是對一個容器；kubectl logs -l <label> 是對一組符合 label 的 Pod。bot 有多個 replica、或 Pod 被重建過（名字換了）時，用 label 而不是 Pod 名字，你才不用每次先 get pods 查新名字。--since 在排查剛剛那一段時間發生什麼時很順手。--previous 是 Day 14 用過的，看上一次掛掉前的輸出，但它是針對單一 Pod 的上一個容器，所以還是要先用 get pods -l <label> 挑出那一個 Pod 名字，不是靠 label 就能免掉。

但這些都還是「現在還在叢集裡的 Pod」的 log。Pod 被驅逐或刪掉之後，kubelet 留在節點上的 log 檔不一定會長期保留，要看節點上的輪替和清理設定，你不能假設回頭還找得到。這是跟 compose 最大的差別之一：compose 的容器不會被平台主動重建，docker logs 的內容一直在；K8s 的 Pod 是可拋棄的，log 要送出去存才算數。

Log 聚合：最小可行是什麼

我目前的理解是，對一個 side project 規模的叢集，log 聚合不需要一開始就上整套 ELK 或 Loki，而是三選一：

1. 雲端 managed K8s 自帶的：GKE、AKS 都有把容器 stdout 收進各自 logging 服務的整合。這是 Week 5、6 會回頭講的優點之一。
2. 自架叢集上跑一個輕量收集器：以 DaemonSet 在每個節點跑一個 agent，把 stdout 送去集中的地方。Kubernetes 官方的 Logging Architecture 把這叫 node-level logging agent，是官方列出的做法之一；具體選哪個元件，我還沒踩到底。
3. 什麼都不裝，先把 log 寫到 stdout：這是我在 k3s 沙盒階段的選擇。理由是 Day 11 說的，現在裝 log stack 太早，你還在學 Pod。

不管選哪個，前提都一樣：bot 要把 log 寫到 stdout / stderr，不要寫進容器裡的檔案。kubectl logs 跟雲端的收集器預設都只收這兩條。我的 OpenAB bot 在 compose 時代就是這樣寫的，這點搬過去不用改。

跟 docker stats 差在哪：一張對照

最後一列是我覺得 AI 工程師最容易低估的差別。compose 時代我從沒想過 log 會不見，因為容器一直在那裡；K8s 的 Pod 不會給你這個保證，Pod 換了節點上的 log 就不保證留著。

明天 Week 4 開始，退一步問一個更基本的問題：你的 agent 真的需要 K8s 嗎？

今日一句話

K8s 的 Pod 是可拋棄的，所以觀測的第一原則是把資料送出去：log 進 stdout、metrics 交給 metrics-server，其他的等你真的需要再裝。

延伸閱讀

• Kubernetes 官方：Logging Architecture
• Kubernetes 官方：Resource metrics pipeline
• K3s 官方：Managing Packaged Components