

Kubernetes 容量规划（Capacity Planning）实践指南

云原生SRE

2025-09-17

导读：欢迎点击下方👇关注我，记得星标哟~

欢迎点击下方👇关注我，记得星标哟~

文末会有重磅福利赠送

Kubernetes 容量规划（Capacity Planning）实战与方法论指南

本文提供了关于Kubernetes容量规划的入门指南，强调从大致估算开始、从错误中学习以及逐步优化资源分配的重要性。文章涵盖了扩展策略、节点利用率和弹性，同时解决了噪声邻居、第三方应用资源需求和云服务提供商限制等挑战。

1. 为什么容量规划难？（问题背景）

很多团队第一次构建 Kubernetes 平台就会面临这些灵魂拷问：

• 领导：为什么成本上涨？什么时候能降本？
• 开发：为啥不给我多加点 CPU / 内存？
• 云厂商：配额快到上限了，请申请提升。
• 平台团队：到底该准备多少节点？要不要先按最小集群？滚动升级怎么留冗余？

容量规划的本质：在满足可用性 / 性能 / 弹性目标的前提下，做到资源配置的可预期、可度量、可优化。
预期：第一次一定“不完美”，但必须“结构化 + 可迭代”。

2. 容量规划的目标与核心输出

规划不是拍脑袋，它应输出一组结构化结果：

1. 初始节点池规格与数量（按工作负载类型拆分）
2. 资源利用率目标区间（CPU / 内存 / Pod 密度）
3. Buffer（升级、故障、突发、增长）策略
4. 扩缩策略矩阵（HPA / VPA / Cluster Autoscaler / Karpenter）
5. 隔离模型（按 CPU Bound / Memory Bound / SLA / 合规要求）
6. 自动化 T-Shirt Sizing 模板体系
7. 持续评估指标与再规划周期

3. 关键概念与指标

• 容量（Capacity）：物理或虚拟节点的总资源（vCPU / Memory / 可调度 Pod 数）。
• 可用容量（Effective Capacity）：扣除系统与守护进程后可供业务调度的部分。
• 需求（Demand）：业务 + 平台服务 + 第三方组件实际或预测的资源请求（Requests 层面）。
• 利用率（Utilization）：[]ActualUsage / EffectiveCapacity]（可用基于 Requests 或实测 Usage）。
• 密度（Density）：每节点平均承载 Pod 数。
• Buffer：为升级、Failover、突发流量、增长预留的容量。

4. 流程总览

5. 节点可用容量的推导

节点资源并非 100% 可用。需扣除：

• OS + kubelet + container runtime
• CNI / CSI 插件
• DaemonSet（日志、监控、安全）
• 预留驱逐阈值（Eviction Threshold）

简化近似公式（经验值，初期用 15%~25% 作为系统开销）：
[EffectiveCapacity_{node} = RawCapacity_{node} \times (1 - OverheadRatio)]

示例：一台 4 vCPU / 16 GiB 节点，估算 Overhead=20%
[EffectiveCPU = 4 \times 0.8 = 3.2] vCPU
[EffectiveMem = 16 \times 0.8 = 12.8] GiB

6. 如何估算 T（总需求）

将需求拆分模块：

组成	示例来源	计算方式
业务工作负载	Deployment / StatefulSet	汇总 Requests（非 Limits）
平台组件	Ingress, Metrics, GitOps, ServiceMesh	固定基线
第三方服务	Redis, PostgreSQL, MQ, Search	参考 Benchmark 或现网使用
Buffer-增长	新增功能 / 用户量预期	线性/指数预测
Buffer-突发	活动 / 高峰	最大峰值比平峰提升率
Buffer-升级	滚动升级并发 Pod 迁移	通常 10%~20%
Buffer-故障	N-1 / AZ 失效	按失去 1/N 节点再承载全部

推荐初期粗估：
[T = (业务 + 平台 + 第三方) \times (1 + 增长率) + 升级Buffer + 突发Buffer]

7. 不同环境的利用率目标

环境	推荐目标 CPU Requests 利用率	理由
Dev/Test	65%–75%	频繁重建/调度成本高
Perf/Staging	75%–85%	更接近真实流量，验证峰值
Production	80%–90%（Requests）	成本 vs 风险平衡，留出可突发区间

注：实际 CPU Usage 通常 < Requests；如使用 VPA 优化请求后可提升密度。

8. 按特性分类：CPU Bound vs Memory Bound

快速判定：

• CPU Bound：高 QPS 算法 / API / 流式计算，CPU 使用率接近或超出 requests。
• Memory Bound：缓存、JVM、大数据组件，内存接近 limits，CPU 空闲。
• I/O / Network Bound：数据库代理、网关、日志采集。

建议：分离到不同 Node Group，避免调度器将 Memory Bound 与 CPU Bound 混杂导致整体碎片化。

9. T-Shirt Sizing 模型（示例）

尺寸	Requests (CPU)	Requests (Memory)	典型场景
XS	50m	64Mi	事件驱动小任务
S	100m	128Mi	轻量 API / 辅助服务
M	250m	256Mi	中等业务逻辑
L	500m	512Mi	较重业务处理
XL	1000m	1Gi	CPU 密集 / JVM
2XL	2000m	2Gi	重型服务 / Data Preproc

自动化：基于标签（例如 app.size=S）在 CI/CD 模板中渲染 Deployment。

示例清单模板（Helm values 中定义尺寸映射）：


   # values.yaml
sizes:
  S:
    cpuRequest: 100m
    cpuLimit: 300m
    memRequest: 128Mi
    memLimit: 256Mi

# 模板 excerpt
resources:
  requests:
    cpu: {{ index .Values.sizes .Values.sizeKey "cpuRequest" }}
    memory: {{ index .Values.sizes .Values.sizeKey "memRequest" }}
  limits:
    cpu: {{ index .Values.sizes .Values.sizeKey "cpuLimit" }}
    memory: {{ index .Values.sizes .Values.sizeKey "memLimit" }}

10. 第三方组件的影响

Stateful 服务（Redis / PG / Kafka）：

• 资源峰值更稳定 → 使用固定节点池或独立集群
• 建议设置 Requests ≈ 实际平均 + 15% 安全余量
• 对 I/O / 网络有特殊需求时，选择更高网络带宽实例型

11. 云厂商限制与配额

示例（EKS Pod 数计算）：
[MaxPods = ENICount \times (IPv4PerENI - ReservedIPs) + 2]

m5.2xlarge（示例值）：ENI=4，每 ENI 15 个 IPv4，Reserved=1
[MaxPods = 4 \times (15 - 1) + 2 = 58]

典型限制：

• AKS 默认单节点 Pod 上限 110（CNI 模式可变）
• EKS IP 枯竭将导致 Pending（需监控 CNI 分配失败）
• GKE Autopilot 使用不同调度与计费模型（规划关注配额）

12. 监控与度量（PromQL 示例）

PromQL 示例：

• CPU 请求利用率：
[]sum(rate(container_cpu_usage_seconds_total{image!=""}[5m])) / sum(kube_pod_container_resource_requests{resource="cpu"})]
• 内存请求利用率：
[]sum(container_memory_working_set_bytes{image!=""}) / sum(kube_pod_container_resource_requests{resource="memory"})]
• Pod Pending 率：
[]sum(kube_pod_status_phase{phase="Pending"}) / sum(kube_pod_status_phase)]
• 节点碎片化（可调度但不足以承载最大 Pod）：需自定义 Exporter 或调度模拟
• IP 利用率（EKS CNI）：
[]sum(aws_cni_allocated_ips) / sum(aws_cni_total_ips)]

可视化分类 Dashboard：

• 按 Node Pool：CPU vs Mem 利用率热力图
• 按应用尺寸（label: app.size）
• 扩缩事件时间线（HPA / CA / Karpenter）

13. 常见误区

误区	说明	修正
只看实时 Usage	CPU Usage 波动大，低谷误导	以 Requests + 峰值 Usage 双参考
不区分工作负载类型	统一调度导致碎片化	分类 Node Pool
仅依赖 AutoScaling	没 Pending 就不扩容	预留升级与故障 Buffer
过度追求高利用率	降低弹性与稳定性	设定区间而非单点目标
忽视 IP / Pod 上限	出现 Pending 但节点利用不高	监控 CNI/IP 利用率
直接启用 VPA 自动模式	高频重建影响稳定	先 Observe 模式