按平均内存设置限制，应用可能在启动或批处理时被终止；统一给每个服务很大资源，又可能浪费容量。资源配置需要基于负载阶段、业务目标和故障余量。
观察启动与稳定期之外的变化
收集启动、流量高峰、导出和定时任务时的 CPU 与内存，并关联请求量。一次低峰截图无法代表需求。对持续增长的内存还要排查泄漏或缓存无界，不能只靠提高上限延后问题。
申请量与限制承担不同职责
requests 参与调度判断，limits 约束使用范围。具体行为还受资源类型与平台配置影响。修改配置前应说明要改善调度、控制争用还是防止单实例过度消耗。
为整个节点留出余量
应用副本之外还有系统组件、日志采集和其他工作负载。只把业务容器的配额相加，可能低估节点实际消耗。上线前检查故障或滚动更新时，剩余节点是否能够承载。
用小范围配置变更验收
选择一个服务调整，比较响应分布、重启、节流与资源使用。若出现内存终止，保留证据判断峰值与泄漏，不要在缺少观察时反复试数字。
常见问题：limits 配得越大越稳定吗？
不一定。更大的上限可能减少局部终止，也可能让共享节点争用加重，稳定性需要结合整体容量评估。
技术参考：Kubernetes：容器资源管理。具体接口与配置请结合使用版本核对。
将评估落实到你的系统
如果你的 .NET 应用还缺少可重复的部署、观察或恢复流程，可以通过容器化与自动化交付服务梳理现状，约定实施内容、演练场景与运维交接方式。