服务上线前，怎么估算 Pod 资源

「

这是 2026 年第 1 篇文章。一次压测踩坑，让我意识到：上线前的资源估算不是照抄，而是基准测试。

—— 技术手记

📋 本篇导读

01 为什么需要基准测试：单请求资源消耗是估算的起点

02 怎么做基准测试：五步法和余量计算

03 怎么定 requests 和 limits 的比例：从保守到激进的三种策略

最近上线一个基于 APISIX 网关服务，期望单 Pod 的 QPS 可以达到 4000。最开始资源的配置我参考一个业务服务的资源配置，给 Pod 设了 400m CPU / 512Mi 内存。然后信心满满地开始压测，100 并发、500 并发、1000 并发三轮打下去——QPS 才 1000 出头，离目标差了4 倍。

于是查看了监控发现了问题，分配的资源有问题。网关主要是做执行插件、路由匹配、请求转发工作，属于CPU 密集型，但是业务服务基本都要涉及业务计算、数据库查询等工作，属于IO 密集型。两者完全是不同类型的，所以不要直接拿来参考。

这次踩坑让我意识到，上线前的压测最好要估算好资源的分配，而不是直接照抄。如何初期的资源分配估算的过程其实就是基准测试。

WHY

01 为什么需要基准测试

核心目的：基准测试的核心目的是测试单请求的资源消耗，然后再推算目标 QPS 下所需要的资源量。

一开始想直接进行压测，直接测出服务的性能上限。但一开始连单个请求需要多少资源都不知道，所以更加不知道怎么给 Pod 分配多少 CPU 和内存。只有基准测试后才能更好的往后的性能测试。

基准测试建立性能基本线，性能测试是测试出系统的极限。

· · ·

METHOD

02 怎么做基准测试

基准测试分为五个步骤，每一步都有明确的记录和计算目标。

• 第一步：分配最小配置——一开始可以先分配一个最小的资源，让 Pod 跑起来，服务能够运行起来就行，大概可设置：200m CPU / 256Mi 内存。

• 第二步：先执行低并发压测——先进行10 并发（3-5min）进行一轮压测，然后记录：实际 QPS、CPU 使用率、内存占用。

• 第三步：计算单请求资源消耗

　　单请求 CPU 时间 = （CPU 配置 × CPU 使用率） / 实际 QPS，如单请求 CPU 时间 = (200m × 0.5) / 200 = 0.5ms

　　再进行两轮不同并发的压测，比如 10 并发和 50 并发，然后计算单请求内存：单请求内存 = （50 并发内存 - 10 并发内存） / （50 - 10）

• 第四步：推算目标 QPS 所需资源

　　CPU = 目标 QPS × 单请求 CPU 时间

　　Memory = 进程基础内存 + 单请求内存 × 目标并发数

• 第五步：增加余量

根据公式推算出来的值，只能算是理论值。在实际应用时候还要很多其他因素会产生影响，比如请求响应不均匀、程序 GC 产生 CPU 波动、突发流量等。

所以，一般建议 CPU 加20-30% 余量，内存加 20-30% 余量。

CPU limits = CPU 需求 × 1.2 ~ 1.3

内存 limits = 内存需求 × 1.2 ~ 1.3

· · ·

CONFIG

03 怎么定 requests 和 limits 的比例

分配资源是给容器分配 CPU 和内存，其中要设置基本资源容量 requests，也要设置极限容量 limits。

• requests：Pod 调度时的最低资源保证，决定了 Pod 会被调度到哪个节点。

• limits：Pod 最多能使用的资源上限。

资源分配的三种策略，从保守分配到激进。

• requests = limits：最稳定的配置方式，但是成本最高，这种只适合在核心服务中这样使用，核心服务对延迟极度敏感。

• requests ≈ limits 的 60-70%：比较折中的方案，兼顾稳定和成本，但需要注意的是若节点资源紧张就可能产生 CPU 限流，基本大部分线上服务使用这种方式都可以满足。

• requests << limits：非核心/允许服务抖动的服务可以配置 requests 资源小一点，常规配置：CPU（25%-33%），Memory（50%）。这样设置成本低，资源利用率也比较高。主要因为这种非核心服务 QPS都不太稳定。

⚠️ 注意：分配资源时一定不要做的行为：只配置了 requests 没有配置 limits。当时为了省方便就只设置 requests，这种配置会导致它使用节点剩余的全部 CPU，这样可能就会影响邻居容器。

资源分配总结一句话：一般在线业务：CPU 用 60%~70%，内存用 70%~80%；核心服务一律 100%

· · ·

RATIO

04 为什么 60-70% 是折中方案

CPU 是可压缩资源。当 CPU 使用率超过 limits 时，服务不会被杀死只会被强制限流，这样就会导致 CPU 使用率没有满，但是 QPS 上不去，P99 却很高。

如果 requests 设得太低（比如 limits 的 10-15%），如果服务有接口需要更大资源时，就会很容易超出 limits，你的服务就会被throttle，就会发生性能抖动。

所以设置60-70% 的比例，不仅调度时保证了可使用大部分 CPU，也预留了 30-40% 的弹性空间。

计算公式：requests = limits × 0.6 ~ 0.7

· · ·

PRACTICE

05 实践：用 APISIX 的数据验证推算

回到我们的案例。如果当时我做了基准测试，推算过程大概是这样的：

而实际最终我们调到的配置是limits = 2000m / 2Gi，QPS 稳定在 3000+。推算值和实际值量级一致，而不是一开始 400m 那种差 5 倍的离谱。

所以基准测试的价值不是“精确预测”，而是让你不偏离目标。

· · ·

SUMMARY

06 基准测试 SOP 总结

1. 用最小配置起 Pod（如 200m/256Mi）

2. 低并发（10-20）压测 3-5 分钟

3. 记录：QPS、CPU 使用率、内存占用

4. 计算单请求 CPU 时间 = (CPU 配置 × 使用率) / QPS

5. 推算：目标 QPS × 单请求 CPU 时间 = CPU 需求

6. 加 20-30% 余量 → 得到 limits

7. requests = limits × 60-70%

8. 内存同理：推算后加余量

如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见