容器应用部署所需的计算资源评估，不宜只按开发环境的配置照搬。关键是看真实负载下的 CPU 使用、内存峰值和流量变化，再把容器配置与节点可分配资源对应起来。下面的方法适用于 Kubernetes 等容器平台，也适用于自行管理容器的环境。
先分清容器配置和机器余量
以 Kubernetes 为例，requests/limits分别表示调度时预留的资源和容器可使用的上限。CPU 通常以核或毫核表示，1000m 等于 1 核；内存常以 Mi、Gi 表示。CPU 达到 limit 时可能发生 CPU throttling，即被限制运行时间；内存超过 limit 则可能触发 OOM 终止进程。因此，两者不能简单按同一种“超量”处理。
节点也不能把物理总量全部分给应用。操作系统、容器运行时、集群组件及监控日志代理都会占用资源。可先按节点可分配容量规划，并把约 10%—20% 留作调度和负载波动余量；这是起始估算范围，不是固定标准，组件较多或故障切换要求较高时应留得更多。
用负载数据估算 CPU 与内存
CPU：看持续负载，也看突发
先观察请求量较高时的 CPU 使用，而非只取一天平均值。对延迟敏感的在线服务，可把稳定时的使用量作为 requests 的参考，再根据峰值、并发和扩容速度设置 limit。比如一个服务在代表性测试中稳定使用约 0.4 核、短时峰值约 0.9 核，可从 requests 约 500m、limit 约 1 核开始验证；若测试中持续触顶或出现限流，就要增加额度或优化程序，而不是盲目复制这个示例配置。
批处理、编译等可延后任务更适合关注总完成时间和峰值吞吐；交互式服务则还要观察响应延迟。CPU 使用长期接近 limit、延迟随并发上升，通常意味着配置不足或代码效率需要排查。
内存：以工作集和峰值为准
记录进程实际常驻内存及容器的 working set（近期活跃、通常需要留在内存中的数据），同时覆盖缓存、运行时堆、线程栈和同容器内的辅助进程。内存不像 CPU 一样容易通过限速平滑处理，峰值超过上限可能直接导致重启。可用多次高负载测试的峰值作为基础，再加约 20%—30% 的初始余量；启动时会一次性加载大数据或流量有明显季节波动的服务，需要单独测试。
按步骤得到初始配置
列出负载条件。记录正常与高峰请求量、并发数、任务批次和数据规模；压测应尽量接近预期生产流量。
采集实际用量。至少覆盖一个完整业务周期，并关注高峰时段。读取容器监控中的 CPU、内存和重启情况；只有平均值时，不要据此直接定上限。
设置首轮 requests 与 limits。CPU requests 参考稳定负载，limits 根据峰值承受能力和延迟目标确定；内存 requests 参考常态工作集，limit 则覆盖经验证的峰值及余量。
核算副本与节点容量。将单个副本的 requests 乘以副本数，再加平台组件和其他工作负载。确认节点可分配资源能够承载计划中的副本，并考虑一个节点不可用时剩余节点是否仍能调度关键服务。
上线后复核并调整。观察至少覆盖高峰与低谷的运行数据。若 CPU 经常触顶，检查限流、并发和扩容速度；若内存持续增长或频繁 OOM，检查泄漏、缓存和峰值负载，再逐步改配置。
自动扩容和预留量怎么配合
水平自动扩容（Horizontal Pod Autoscaling）能按指标增加或减少副本，但不能替代单个容器的合理配置，也不能凭空创造节点容量。扩容规则要考虑启动耗时、镜像拉取和节点剩余资源。内存扩容尤其要谨慎：若指标随缓存自然增长，单纯增加副本未必能消除内存压力。建议先验证扩容触发条件和节点容量，再确定可承受的副本范围。
常见问题
开发环境用量很低，能直接按它配置吗？
不建议。开发环境的流量、数据量和并发通常不同，应结合生产近似数据或压测结果估算。
CPU limit 是否一定要设置？
取决于平台策略和服务特性。设置上限能限制单容器占用，但过低会造成 throttling；应通过负载测试和线上指标确定。
内存预留 20%—30% 是否适用于所有应用？
不是。它只是初始参考范围，最终要根据实际峰值、运行时行为、缓存策略和业务波动调整。
多久重新做一次评估？
大幅改版、流量增长、数据规模变化或出现持续限流、OOM 后应复核；平稳运行时也可定期对照监控数据检查配置。
归根结底，容器应用部署所需的计算资源评估应以代表性负载的实测数据为依据：CPU看稳定用量与突发能力，内存看工作集与峰值，同时为节点和扩缩容留出空间。
