如何估算Kubernetes环境下Pod所需的资源配额

首先明确K8s的基础资源规则：CPU资源以m（千分之一核）为单位，本质是CPU时间分片配额，1000m代表每秒可独占1个逻辑核心的全部运算时间，属于可压缩资源，超出配额只会降速不会直接终止Pod；内存属于不可压缩资源，超出配额会触发OOM，直接导致Pod被驱逐或重启。
以下是经过生产验证的估算、配置最佳实践：

1. 初始配额优先基于真实负载数据确定 #

• 新上线的正式业务，先在测试环境跑满峰值压力压测，持续观测24小时以上的Pod级资源监控数据，取CPU使用率P95值作为requests的CPU基准，内存使用率P99值作为requests的内存基准；limits的值可以对应设为requests的1.2~2倍，覆盖突发流量场景。
• 没有压测条件的非核心业务，可以参考同类型、同量级业务的历史资源使用均值，上浮20%作为初始requests值，上线后观测7天再调整。
• 禁止直接拍脑袋设置配额：CPU设得过低会导致业务响应延迟上升，内存设得过低会导致高频OOM，配额过高则会造成严重的资源浪费。

2. 按业务等级匹配requests/limits配比 #

• 核心在线业务（如交易、用户鉴权等）：内存的requests和limits设为相同值，确保Pod的QoS等级为Guaranteed，节点资源不足时不会被优先驱逐；CPU的limits可以设为requests的1.5~2倍，应对突发的流量峰值。
• 非核心在线业务（如后台管理、运营工具等）：requests可以设为P80的使用率数值，limits设为P99.9的数值，允许一定程度的资源超配，提升集群整体利用率。
• 离线计算业务（如定时任务、日志清洗等）：requests可以设得更低，仅保留基础运行所需的资源即可，limits按峰值的1.2倍设置，避免任务异常占满节点资源。

3. 定期动态调整配额 #

• 新业务上线前2周，每周排查一次资源使用率：如果连续7天资源使用率低于requests的30%，直接下调requests数值；如果连续3天峰值使用率超过limits的80%，及时上调limits避免业务受损。
• 避免requests设置过大导致资源碎片化：比如8核16G的节点，如果大量Pod设置4核8G的requests，很容易出现节点剩余资源总量足够，但凑不出单个Pod所需的连续配额，导致Pod调度失败。
• 所有Pod必须配置requests和limits：没有配置配额的Pod QoS等级为BestEffort，节点资源不足时会被第一优先级驱逐，且异常时可能占满整台节点的资源，影响同节点其他所有业务。

4. 特殊业务场景适配 #

• JVM类Java服务：内存配额要比JVM启动参数中设置的堆内存大20%~30%，预留足够的堆外内存空间，避免堆外内存占用超出limits触发OOM。
• 有内存泄漏风险的服务：内存limits不要设置过大，同时配置OOM告警，触发时及时排查代码问题，避免泄漏的内存持续占用节点资源。
• 高并发微服务：CPU配额不要设置过小，避免流量高峰时CPU时间不足导致请求大量超时。

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