K8s Pod数量与CPU请求配比最佳实践及性能对比问询

两种场景的运行速度对比 #

没有绝对的性能优劣，完全取决于你的业务类型：

• CPU密集型业务（如数据计算、音视频编码、加解密逻辑）：1000m请求+2副本的方案性能更好。2个Pod各自独占1个vCPU的调度优先级，几乎没有CPU上下文切换、CPU缓存失效的额外开销；20个小规格Pod需要频繁争抢CPU时间片，额外开销通常会拉低10%~30%的实际吞吐，延迟毛刺也会更多。
• IO密集型业务（如Web接口、微服务网关、数据库代理，大部分业务时间在等待网络/存储返回）：100m请求+20副本的方案性能更好。这类业务CPU本身不是瓶颈，更多副本可以承接更高的并发请求，单Pod故障的影响面也更小，负载均衡效果更均匀。

配置选型通用准则 #

无需压测就可以优先遵循的规则：

• 单Pod的CPU请求不要小于100m：低于这个阈值K8s CPU调度精细度不足，AWS EC2本身的CPU时间片分配也无法保障稳定的计算资源，很容易出现无理由的延迟毛刺。
• 单Pod的CPU请求不要超过节点单vCPU规格（即2vCPU节点上最多设1000m）：避免跨vCPU调度产生的NUMA访问开销，AWS通用型EC2的单vCPU对应独立的物理线程，跨核调度的额外开销很高。
• 2vCPU节点的总Pod数控制在20个以内：AWS EKS对2vCPU实例（如t3.medium、c5.large）的默认Pod运行上限就是17~20个，更多Pod会导致CNI网络转发、kubelet管控的开销陡增，反而拖累整体性能。
• 若配置了CPU limits，优先选大规格少Pod的方案：小规格Pod的CPU限流阈值更低，突发流量下更容易被内核throttle，导致延迟升高。

什么时候需要性能测试确定最优值？ #

如果符合以下任意场景，必须用真实业务流量做压测才能确定最优配比：

• 业务属于CPU+IO混合场景，特征不明确
• 对延迟稳定性要求极高（如P99延迟要求低于100ms）
• 需要搭配HPA自动扩缩容，要匹配扩缩容阈值和Pod规格的适配性

内容的提问来源于stack exchange，提问作者user2449394