部署成功 ≠ 上線就 OK
上一篇做完 12 步部署，所有 Pod 都 \Running\，Ingress 也通了。可以下班了嗎？
不行。Running 不代表撐得住流量。生產上線前你還要回答 3 個問題：
回答這 3 題的方法叫做 混沌工程（Chaos Engineering）——主動製造故障，看系統怎麼反應。
場景設定：短網址服務
我們用一個簡單的短網址 API 為例：
\\\
POST /shorten { url } → { short_id }
GET /:short_id → 302 redirect
\\
部署 4 個 Pod，配 HPA 1 → 10 個。
試煉 1：壓力測試
工具選擇
| 工具 | 適合 |
|---|---|
| hey | 簡單、輕量，3 秒上手 |
| k6 | 進階腳本、有報告 |
| Apache Bench (ab) | 老牌，功能基本 |
| wrk | 純 C，性能極佳 |
\\\bash
# Mac
brew install hey
# Linux
go install github.com/rakyll/hey@latest
\\\
第一輪：基準（2 並發）
\\\bash\
hey -z 30s -c 2 http://myapp.local/api/healthz
\\
\\\
Summary:
Total: 30.00 s
Requests: 1500
Average RPS: 50
Latency: 40ms (p99: 120ms)
Status 200: 1500 (100%)
\\
✅ 基準正常。
第二輪：加壓（50 並發）
\\\bash
# 終端 1：監控 HPA
kubectl get hpa -n prod -w
# 終端 2：壓測
hey -z 60s -c 50 http://myapp.local/api/health
\\\
終端 1 該看到：
\\\
api-hpa 125%/70% 3
api-hpa 125%/70% 5
api-hpa 90%/70% 7
api-hpa 65%/70% 7 ← HPA 工作中
\\
如果 Pod 沒擴：
- 確認 \
metrics-server\跑起來 - 確認 Deployment 有設 \
resources.requests\ - 看 \
kubectl describe hpa api-hpa\的 events
第三輪：極限（500 並發）
\\\bash\
hey -z 60s -c 500 http://myapp.local/api/health
\\
這時候你應該開始看到：
\\\
Status 200: 8000 (95%)
Status 503: 420 (5%) ← 開始有失敗
Latency p99: 3500ms ← 慢得很
\\
這就是極限。記下這個數字——它是你「該再加 maxReplicas」或「該優化 DB 連線池」的訊號。
試煉 2：故障模擬
Test 1：殺 Pod
\\\bash
# 邊壓測邊殺 Pod
kubectl delete pod -n prod -l app=api --field-selector=status.phase=Running --wait=false &
# 看 Deployment 的反應
kubectl get pods -n prod -l app=api -w
\\\
預期結果：
- 舊 Pod 進入 \
Terminating\ - 新 Pod 立刻被建立
- Service 會自動把流量導到健康的 Pod——但前提是 readinessProbe 設好了
Test 2：Cordon Node（模擬 Node 掛掉）
\\\bash
# 看 Pod 在哪個 Node
kubectl get pods -n prod -o wide
# 把某個 Node 標記為「不要再排 Pod 上來」
kubectl cordon worker-1
# 把上面的 Pod 趕走（drain）
kubectl drain worker-1 --ignore-daemonsets --delete-emptydir-data
\\\
預期結果：
- worker-1 上的 Pod 全部被驅逐
- K8s 自動在其他 Node 重新排 Pod
- 服務應該還是可用（因為 replicas ≥ 2）
\\\bash\
kubectl uncordon worker-1
\\
Test 3：DB 連線池爆掉
短網址服務最容易出事的是 DB 連線。模擬：
\\\bash
# 故意把 DB 限制到 5 個連線
kubectl exec -it mysql-0 -n prod -- \\
mysql -uroot -p -e "SET GLOBAL max_connections = 5;"
# 然後狂壓 API
hey -z 30s -c 100 http://myapp.local/api/shorten -m POST -d '{"url":"https://x"}'
\\\
這時候你會看到：
- API Pod 卡住，等 DB 連線
- readiness 失敗，Pod 從 Service 摘下
- 流量全集中在剩下的 Pod
- 連鎖反應，整個 API 雪崩
- DB 設合理的 max_connections
- API 程式設 connection timeout
- 加上 connection pool（HikariCP / pgbouncer）
試煉 3：邊界數值
| 測試項 | 怎麼做 | 看什麼 |
|---|---|---|
| OOMKilled | 壓到 Pod 記憶體爆 | RESTARTS 次數變化 |
| Probe 設太嚴 | 把 liveness 設成 1 秒 fail | 整片 Pod 一直重啟 |
| HPA maxReplicas 不夠 | 流量是 maxReplicas 的 2 倍 | 看 Pod 是否打滿後失敗 |
| PVC 滿了 | 寫入超過 PVC 容量 | DB Pod 進入 CrashLoop |
為什麼要刻意搞壞？
「不要等到生產環境出事，才知道哪裡會壞。」
—— Netflix Chaos Monkey（始祖級混沌工程工具）
主動製造故障的好處：
- ✅ 用心理準備好的時候出事，比凌晨 3 點被叫醒好
- ✅ 驗證 Probe / HPA / Replicas 真的有用
- ✅ 找到「Resource limits 設多少才夠」的真實數字
- ✅ 練習團隊面對故障的反應流程
進階工具
| 工具 | 用途 |
|---|---|
| Chaos Mesh | K8s 原生混沌工程平台 |
| Litmus | 預設模板豐富 |
| kube-monkey | Netflix Chaos Monkey 的 K8s 版 |
| k6 | 帶 chaos 模式的壓測 |
重點整理
- Running ≠ 撐得住：上線前要壓測 + 故障演練
- 3 輪壓測：基準 → 加壓 → 極限，找瓶頸
- 3 種故障：殺 Pod、cordon Node、DB 爆連線
- Chaos Engineering 的精神：主動找弱點、不被動等出事
- 進階：用 Chaos Mesh / Litmus 做自動化混沌測試
下一步
到這裡，你已經會做完整的生產級部署、會壓測、會故障演練——這就是「生產就緒」的標準了。
接下來是 Group 6 的速查表，這 3 篇是隨手查的工具：kubectl 速查表 → YAML 範本速查表 → 學習 Roadmap
📅 下一篇：kubectl 指令速查表:50 個最常用指令
從這篇開始進速查表階段——50 個最常用指令一頁查完,工作上書籤頁等級的工具。
📚 完整系列總覽：K8s 系列教學首頁（共 40 課，按學習路徑順序排）