Day 21｜第一階段總結 × 資源調校：Requests / Limits + 效能測試

● 前言

前 1～20 天，我們完成了 DevOps 的基礎工法（從版本控制、容器化、K8s、Helm、Terraform、Observability）。
在總結之前，我們最後聚焦一個核心觀念：「效能與資源調校」。
這不是單純的指令，而是 如何理解服務資源配置，並透過測試數據找到最佳平衡。

● Requests / Limits 的意義

• Requests：保證 Pod 至少能獲得的資源（CPU / Memory）。
• Limits：Pod 能使用的資源上限，避免某個 Pod 搶走所有資源。

👉 本質：資源分配策略 × 集群穩定性

● 效能測試的角色

⚙️ 壓測工具（ab, k6, locust）不是為了「跑到爆炸」，而是為了 驗證資源設定是否合理。

常見情境：

• Requests 太低 → Pod 容易被 OOMKill
• Limits 太高 → 某個 Pod 把 Node 吃滿，其他 Pod 餓死
• 測試數據能告訴我們：什麼設定下服務最平穩

● 對比圖：資源調校的三種情境

⚠️ 太低

• Requests：幾乎 0
• Limits：無限制
• 結果：Pod 搶不到資源，常發生 OOMKill
  （註：OOM = Out Of Memory，系統記憶體不足）

🚨 太高

• Requests：過低
• Limits：無上限
• 結果：某些 Pod 壟斷資源，其他服務受害

✅ 合理

• Requests：基於壓測數據
• Limits：適度限制
• 結果：服務平穩運行，資源利用率最佳

● 第一階段知識地圖（Day 1～21 回顧）

👉 從 DevOps 基礎 → CI/CD → 容器化 → Kubernetes → Terraform/IaC → Observability → 資源調校，我們已經串起一條完整的學習脈絡。

● 第一階段總結：CALMS 對照

• Culture：從 Day 1 就強調團隊協作與流程透明
• Automation：GitHub Actions、Jenkins、Terraform、Helm → 一條龍自動化
• Lean：Requests/Limits 讓資源「不浪費」
• Measurement：Prometheus / Grafana / ELK → 數據驅動調整
• Sharing：透過這 21 天的文章，知識沉澱＋經驗分享

👉 下一篇

Day 22｜DevSecOps 是什麼？從 DevOps 到安全左移