這幾天 Claude Code 帶我排了七種故障，過程中它沒有直接幫我改 YAML，每一次都是它先解釋現象、列出可能原因、告訴我該下哪些指令，指令我自己下，輸出我自己看，今天先停下來把前面整理一遍
先回頭看 Day 15 那段固定開頭
你是我的 Kubernetes 助教。我是新手，請遵守以下方式協助我：
1. 先解釋目前看到的現象。
2. 不要直接修改 YAML。
3. 先提出最多三個可能原因。
4. 告訴我需要執行哪些唯讀指令。
我覺得最有用的是第 2 跟第 3 條。不准它改 YAML，我自己動手，我才會知道改了哪一行
下面是我請claude把七個故障排成一張表
| Day | 弄壞什麼 | get pods 看到什麼 | 答案在哪 |
|---|---|---|---|
| 16 | Image tag 不存在 | 新 Pod ImagePullBackOff，舊的三個照跑 | describe 的 Events，Failed to pull image |
| 17 | 啟動指令直接 exit 1 | CrashLoopBackOff，RESTARTS 一直加 | logs --previous，Last State 的 Exit Code |
| 18 | Service selector 打錯字 | 全部 Running 1/1，看不出異狀 | describe service，Endpoints 是空的 |
| 19 | readinessProbe 路徑錯 | 新 Pod Running 0/1，部署卡住 | describe 的 Events，Readiness probe failed |
| 20 | memory requests 開太大 | Pending | describe 的 Events，Insufficient memory |
| 21 | memory limits 設太小 | OOMKilled 然後 CrashLoopBackOff | Last State 的 OOMKilled 跟 137 |
| 22 | 改了 ConfigMap | 全部 Running，AGE 沒變 | 進容器看檔案，內容還是舊的 |
這八天有一個共通的前提，每一個故障都是我自己弄壞的。所以我會事先知道有東西壞了，也大概可以知道要去看哪一個。但真實情況通常不是這樣，是使用者先發現、然後才回報，而那時候可能已經壞了幾個小時
接下來七天就要處理這件事，讓叢集自己告訴我不對勁：用 Helm 把監控裝起來、學看 Grafana 跟寫 PromQL，今天這張表裡 get pods 看到的 STATUS 跟 RESTARTS，到時候都會變成可以畫成曲線的數字、把 Day 17 重做一次，看同一個故障在指標上長什麼樣子、自己做一張 Dashboard、然後再放一次故障，這次三個一起放，試著從 Grafana 發現它
明天就先來把監控裝起來，明天見 :D
iThome鐵人賽
看影片追技術