Kubernetes 容量計算器
計算您的工作負載的 Kubernetes 叢集節點需求
如何使用Kubernetes 容量計算器
- 1輸入單個 Pod 的 CPU 與記憶體請求值，以及執行的副本數。
- 2輸入節點規格（CPU/記憶體）與系統預留開銷。
- 3檢視部署前所需節點數與叢集利用率。
估算 Kubernetes 叢集容量
節點數 = ceil(總請求 / (節點容量 × (1 − 系統預留)))；利用率 = 總請求 / (節點數 × 節點容量)Kubernetes 按請求值而非限制值排程，因此必須按請求總和加上系統 Pod 與裝箱損耗的緩衝來規劃。
為每個節點預留 10–20% 給 kube-system 與驅逐閾值，可避免排程器在負載下把節點標記為不可排程。
K8s 容量規劃的基礎是理解 **requests 與 limits 的區別**：`requests` 是排程依據（Kubelet 保證至少這麼多，排程器按 requests 之和決定 Pod 放哪臺節點），`limits` 是硬上限（CPU 超限會被 throttle 限速，記憶體超限會被 OOMKilled）。**只設 limits 不設 requests 是常見錯誤**——排程器會認為該 Pod 不佔資源，導致節點過度擁擠。
**節點容量不是 100% 可用**，要扣掉三部分：① **系統預留（kube-reserved / system-reserved）**——通常 CPU 各預留 0.5–1 核、記憶體各預留 1–2 GB；② **每個節點的系統開銷**——kubelet、容器執行時、日誌、監控 agent，通常 1–2 GB 記憶體；③ **DaemonSet 佔用**（日誌採集、網路外掛 CNI、監控、儲存外掛），通常每節點 0.5–1 核 + 512 MB–1 GB。**經驗值：一臺 8 核 32 GB 的節點，實際可分配給業務 Pod 的約 6 核 26 GB。**另外還要預留至少 10%–15% 的餘量應對突發和節點故障時的重排程。
| 工作負載 | requests.cpu | limits.cpu | requests.memory | limits.memory |
|---|---|---|---|---|
| Nginx 靜態服務 | 100m | 500m | 128Mi | 256Mi |
| Node.js API | 200m | 1000m | 256Mi | 512Mi |
| Java Spring Boot | 500m | 2000m | 1Gi | 2Gi（含 JVM 堆外） |
| Python Django (gunicorn) | 300m | 1000m | 512Mi | 1Gi |
| Redis 快取 | 500m | 2000m | 1Gi | 2Gi |
| PostgreSQL | 1000m | 4000m | 2Gi | 4Gi |
| Prometheus | 500m | 2000m | 2Gi | 4Gi |
K8s 資源請求與限制的典型配置
常見問題
排程看請求值還是限制值？
排程使用請求值；限制值僅約束使用，設過低可能觸發 OOM。
為什麼要預留節點容量？
kube-system Pod 與驅逐閾值需要餘量，否則節點會變得不可排程。
如何改善裝箱率？
合理設定請求值、使用拓撲分佈，並避免過小的節點浪費預留開銷。
CPU limit 會導致效能問題嗎？
**會，而且很隱蔽**。CPU limits 通過 CFS 配額（預設 100 ms 週期）實現，超限會被 throttle（限流）到下一個週期。表現為：應用 CPU 使用率看起來不高（比如只用了 30%），但延遲飆升、吞吐下降——**因為限流發生在 100 ms 粒度內的突發，監控工具通常看不到**。這就是為什麼很多團隊**只設 requests 不設 CPU limits**（讓 Pod 能用到空閒 CPU，靠 requests 保證最低資源）。記憶體 limits 則必須設（防止單個 Pod 拖垮整個節點）。**可以用 kube-state-metrics 的 container_cpu_cfs_throttled_seconds_total 監控限流情況。**
QoS 等級有什麼影響？
K8s 根據 requests/limits 設定分三個等級，決定了**節點資源不足時誰先被驅逐**：**Guaranteed**（requests = limits，所有資源都設且相等）最優先保留，適合關鍵業務；**Burstable**（設了 requests 但 limits 更大或不一致）中等；**BestEffort**（什麼都不設）最先被殺。**所以關鍵服務應設為 Guaranteed**。另外記憶體不足時（節點 OOM），K8s 會按 QoS 等級 + 實際記憶體使用超出 requests 的比例來排序驅逐。理解這一點對設計穩定的叢集很重要。