引言
在容器化部署中，资源限制（Resource Limits）是最容易被忽视、却最容易引发事故的配置项。CPU和内存的Request与Limit设置不当，轻则导致应用性能波动、调度失败，重则引发OOM Kill、节点资源争抢，甚至整条业务链路崩溃。很多开发者的配置习惯是"拍脑袋"：Request设个保守值，Limit设个大数，觉得"总不会出问题"。但现实是，这套"差不多"的配置逻辑，恰恰是生产环境中最大的隐患。天翼云容器服务CTK基于Kubernetes构建，继承了Kubernetes完整的资源管理机制，但工具再好，也需要科学的配置方法来驾驭。本文将从Request与Limit的本质区别出发，结合CPU和内存两类资源的不同特性，给出一套经过实战验证的科学配置方法论。
一、先搞清楚：Request和Limit到底在管什么
很多开发者把Request和Limit混为一谈，认为它们只是"下限"和"上限"的关系。这个理解只对了一半。
Request（请求值），是容器向调度器声明的"我至少需要这么多资源"。调度器在分配节点时，会根据所有容器的Request总和来判断节点是否有足够的空闲资源。如果节点的可用资源小于容器的Request，调度器不会把这个容器放到该节点上。Request的核心作用是调度决策——它决定了容器能被放到哪里。
Limit（限制值），是容器能使用的资源硬上限。超过Limit的CPU会被节流（Throttling），超过Limit的内存会被直接杀掉（OOM Kill）。Limit的核心作用是资源隔离——它决定了容器最多能用多少，以及超额后的惩罚机制。
两者的关系可以用一个比喻来理解：Request是你去餐厅订位时说的"我需要一张四人桌"，Limit是餐厅规定的"每桌最多坐六个人"。Request决定你能不能进这家餐厅，Limit决定你进了之后最多能占多大的空间。
理解了这个区别，你就明白为什么"只设Limit不设Request"是危险的——调度器不知道你需要多少资源，可能把你放到一个资源紧张的节点上，导致你和其他容器争抢资源。而"Request设得太高"同样危险——调度器以为你需要很多资源，把你放到一个大节点上，但你实际根本用不了那么多，造成资源浪费。
二、CPU资源配置：节流比杀进程更可怕
CPU是可压缩资源（Compressible Resource），这意味着当容器使用的CPU超过Limit时，不会被杀掉，而是被节流——内核会强制暂停容器的CPU时间片，让它"等一等"。这听起来很温和，但实际上，节流对业务的伤害往往比OOM Kill更隐蔽、更持久。
Request的配置原则：设为实际使用量的70%到80%。 不要设为峰值，因为峰值是瞬态的，调度器按峰值分配资源会导致严重浪费。也不要设得太低，否则调度器可能把你放到一个已经很拥挤的节点上，即使你的Limit很高，也会因为和其他容器争抢CPU时间片而被节流。
Limit的配置原则：根据业务容忍度设定，但不要无限制地开大。 对于核心业务，建议Limit设为Request的1.5倍到2倍，给突发流量留出缓冲空间。对于非关键业务，Limit可以设为Request的1倍到1.2倍，严格限制其CPU占用，避免影响其他服务。
最容易踩的坑：Limit设得太低。 很多团队为了"省资源"，把CPU Limit设得很紧，比如只给0.5核。结果在流量高峰时，容器被持续节流，响应延迟从几十毫秒飙升到几百毫秒甚至数秒，用户感知到的就是"系统变慢了"。但监控上CPU使用率可能只有50%，因为被节流的那部分根本没被统计进去。这种"假低负载"是最难排查的性能问题之一。
科学的验证方法：在压测环境中，逐步提升CPU Limit，观察响应延迟的变化曲线。 当延迟不再随Limit提升而明显下降时，那个点就是你的最优Limit值。不要凭感觉，要凭数据。
三、内存资源配置：OOM Kill是最残酷的惩罚
与CPU不同，内存是不可压缩资源（Incompressible Resource）。当容器使用的内存超过Limit时，内核不会节流，而是直接触发OOM Killer，把容器进程杀掉。没有商量余地，没有降级处理，直接消失。
这就是为什么内存配置比CPU配置更需要谨慎。
Request的配置原则：设为应用正常运行时的实际内存使用量。 注意，是"正常运行时"，不是启动时，也不是峰值时。很多Java应用启动时会加载大量类库和缓存，内存占用可能是运行时的两到三倍。如果你按启动峰值设Request，调度器会给你分配大量内存，但这些内存在启动完成后就闲置了，造成严重浪费。
Limit的配置原则：设为Request的1.2倍到1.5倍，但绝对不能低于Request。 低于Request没有任何意义——Request已经告诉调度器"我至少需要这么多"，Limit比Request还小，内核会直接拒绝启动容器。对于有内存泄漏风险的应用（比如长期运行的后台服务），Limit可以适当放宽到Request的2倍，但必须配合监控，一旦内存使用持续攀升，立刻介入。
最容易踩的坑：把内存Limit设得等于物理机内存。 有些开发者为了"不让容器被杀"，把Limit设得非常大，甚至接近节点总内存。这在单容器场景下看似安全，但在多容器共节点的场景下，一旦某个容器内存泄漏，它会把节点内存吃光，导致同节点上的所有其他容器全部被OOM Kill——这就是所谓的"一人犯病，全员陪葬"。
科学的验证方法：使用真实流量压测，记录应用在不同负载下的内存使用曲线。 找到内存使用的稳定水位，将Request设在这个水位略上方，Limit设在水位的1.3倍左右。同时开启内存监控告警，当内存使用超过Limit的80%时触发预警，在OOM Kill发生之前就介入处理。
四、CPU与内存的组合策略：不要孤立地看
CPU和内存的配置不能各自为战，必须组合考虑。因为在真实业务场景中，CPU和内存的使用往往是 correlated（相关联的）。
场景一：CPU密集型应用（如视频转码、加密计算）。 这类应用CPU使用率高，但内存占用相对稳定。配置策略是：Request和Limit都以CPU为核心指标，内存Request设为实际使用量的1.1倍即可，Limit可以适当放宽。关键是确保CPU Limit不要设得太低，否则节流会直接拖慢处理速度。
场景二：内存密集型应用（如缓存服务、大数据处理）。 这类应用内存占用高，但CPU使用率低。配置策略是：以内存为核心指标，CPU Request设一个较小的值（如0.25核），Limit设为Request的2倍到3倍，给突发计算留空间。内存Request必须准确，Limit不能低于Request的1.3倍。
场景三：通用型Web服务（如API网关、业务中台）。 这类应用CPU和内存使用都比较均衡。配置策略是：CPU和内存分别按上述原则独立配置，但要注意两者的比例关系。经验值是：每1核CPU搭配2GB到4GB内存。如果你的容器配置是4核CPU但只有1GB内存，或者0.25核CPU却配了8GB内存，大概率是配置失衡。
五、天翼云CTK的实战配置建议
在CTK上配置资源限制时，有几个平台特性需要特别注意。
第一，CTK支持资源超卖。 与自建Kubernetes不同，CTK允许在一定范围内超卖节点资源。这意味着你的Request总和可以略大于节点实际容量，调度器会根据实际负载动态调整。但这不意味着你可以无限制地超卖——超卖比例过高会导致节点资源争抢，所有容器都被节流。建议Request总和不超过节点可分配资源的80%。
第二，CTK的弹性伸缩与资源限制联动。 当配置了HPA（水平自动伸缩）时，新增的Pod会继承Deployment中的资源配置。如果你的Request设得过高，扩容时调度器可能找不到足够资源的节点，导致扩容失败。建议在需要弹性伸缩的场景中，Request设得保守一些，Limit可以适当放宽。
第三，CTK支持在线调整资源限制。 对于已经运行的容器，你可以通过修改Deployment的资源配置来动态调整Request和Limit，CTK会滚动更新Pod。但调整内存Limit需要重启Pod（因为内存限制无法热更新），调整CPU Limit可以不重启。这意味着内存配置要在上线前就定准，上线后再改成本很高。
六、监控与持续优化：配置不是一劳永逸的
资源配置不是"设完就忘"的一次性操作，而是需要持续监控和调优的动态过程。
建议重点监控三个指标：容器实际CPU使用率与Limit的比值（如果长期超过80%，说明Limit设低了）、容器实际内存使用率与Limit的比值（如果超过90%，必须立刻扩容或优化应用）、CPU节流时间占比（如果节流时间占总运行时间的比例超过5%，说明CPU资源严重不足）。
每季度进行一次资源配置审计，对比实际使用量与配置值的偏差。对于长期资源使用率低于Request 50%的容器，果断降低Request，释放调度空间；对于频繁触发节流或接近OOM的容器，及时提升Limit或优化应用代码。
结语
容器资源限制的配置，本质上是在"性能"与"成本"之间找平衡，在"稳定性"与"利用率"之间做取舍。Request决定调度，Limit决定隔离，CPU要防节流，内存要防OOM。没有放之四海皆准的"万能配置"，只有基于真实负载数据反复调优后的"最优配置"。天翼云CTK提供了灵活的资源管理能力，但最终能不能用好，取决于你是否愿意花时间去压测、去监控、去持续优化。资源配置这件事，值得你认真对待。
