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 的比例来排序驱逐。理解这一点对设计稳定的集群很重要。