Kubernetes 资源分配指南：如何科学设置 CPU 与 Memory 的 Request & Limit

前言

在 Kubernetes (K8s) 集群中，服务 YAML 文件里的 resources 配置块往往是被开发者误解最深的区域。面对 requests 和 limits，许多人的做法是“凭感觉填”或者“抄隔壁项目的配置”。

但实际上，这短短几行 YAML 决定了你的微服务在面对突发流量时是安然度过、被无情限流（Throttling），还是直接崩溃（OOMKilled）；也决定了你的 K8s 集群是能够极致降本增效，还是沦为资源浪费的黑洞。

要彻底搞懂参数该怎么设，我们必须先认清 K8s 调度的底层逻辑。

在k8s集群中，我们编写服务yaml的时候有个关键的resources的参数需要填写，但是具体应该怎样设置呢，以下就是我在实际使用过程中的一点思考：

          resources:
            requests:  # 描述服务启动时所需的资源是多少
              memory: "1Gi"
              cpu: "50m"
            limits: # 描述服务最大能使用多少资源
              memory: "3584Mi"
              cpu: "2"

核心基石：K8s 的“瞎眼会计”与 Linux 的“硬核保安”

在决定给服务分配多少资源前，必须理解 K8s 调度和清理资源的两个核心机制：

调度机制：只看账本，不看现实的“瞎眼会计”

K8s 调度器（kube-scheduler）在分配 Pod 到具体 Node 节点时，唯一参考的指标是 requests（账面需求）。
它绝对不会去查看某台宿主机当前的物理真实 CPU 和内存利用率是 10% 还是 100%。只要 节点总容量 - 已调度 Pod 的 Requests 总和 > 新 Pod 的 Request，调度就会成功。
结论： requests 决定了集群的装箱率（调度密度）。设置得越高，节点能调度的 Pod 越少，资源浪费越严重。

清理策略：可压缩与不可压缩资源的冰火两重天

当节点物理资源真正不够用时，Linux 内核与 K8s 节点代理（kubelet）会介入，对 CPU 和内存采取完全不同的镇压手段：

CPU（可压缩资源）：集体变慢，绝不杀人。
- 如果物理 CPU 跑到 100%，系统会根据各个 Pod 的 CPU Request 权重（底层转换为 cpu.shares）重新分配时间片。所有服务都会变慢（RT 飙升），但绝对不会有服务因为 CPU 不够被强杀。
Memory（不可压缩资源）：无情击杀，精准或盲杀。
- 精准击杀（OOMKilled）： 某个 Pod 的实际内存达到了它自己的 Memory Limit，内核的 OOM Killer 会直接杀掉该容器并重启。
- 节点驱逐/盲杀（Eviction/Node OOM）： 如果大量 Pod 没达到自己的 Limit，但宿主机的物理内存总和被吃光了。Kubelet 会拉响警报，强制驱逐那些内存使用量超过自己 Request 的 Pod，以保护节点不死。

逐个击破：四大参数的设置法则

基于上述底层逻辑，我们来推演这四个参数到底该怎么填。

CPU Request：必须设置，且尽量贴近真实低谷

是否应该设置？ 必须设置。 这是 K8s 调度的依据，也是在宿主机 CPU 满载时，你的服务能分到多少最低算力保障的“股权证明”。
设置多少？ 建议通过 Prometheus 观察服务在日常平稳期的真实 CPU 消耗，设置一个偏低的值（例如 50m 或 100m）。这能极大释放账面调度空间。
如果你在 Kubernetes 中完全不设置 CPU Request，K8s 会根据你是否设置了 CPU Limit 触发两种截然不同的底层机制。

但结论可以先放在前面：这是一种极其危险的做法，会导致你的服务在集群高负载时“离奇假死”。

我们来拆解这两种情况的底层逻辑：

情况一：既不设 CPU Request，也不设 CPU Limit（最惨的“底层平民”）

当你两个都不写时，K8s 会认为这个 Pod 对 CPU 的需求是 0。

调度层面（瞎眼分配）： 既然你需要 0 个 CPU，K8s 调度器（kube-scheduler）会认为随便哪个节点都能塞下你。它会把你当成没有任何计算需求的“空气”，闭着眼睛把你调度到可能 CPU 已经负载 100% 的节点上。
运行层面（完全丧失竞争权）： 当你的 Pod 运行在宿主机上时，Linux 内核会给它分配一个全场最低的 CPU 权重（在 cgroups 底层，cpu.shares 默认只有 2，而 1 个核心的权重是 1024）。
致命后果 —— “饥饿假死”（Starvation）：
- 平时（节点空闲）： 你的程序跑得飞快，因为没人跟你抢，你可以占用节点 100% 的 CPU。
- 战时（节点满载）： 当同节点的其他服务（那些设置了 Request 的“特权阶级”）也开始狂用 CPU 时，Linux 内核会严格按照权重分配时间片。你的服务因为权重是底层的底，几乎分不到任何 CPU 运算时间。
- 表现： 你的 Pod 依然显示 Running，没有报错，没有 OOM，甚至都没被重启。但是你的接口请求会全部卡住、疯狂 Timeout，整个服务处于一种“脑死亡”状态，直到宿主机的 CPU 空闲下来它才会突然“复活”。

情况二：没设 CPU Request，但设了 CPU Limit（触发 K8s 潜规则）

如果你只写了 Limit: 2，而把 Request 留空，K8s 为了防止逻辑冲突，会强制执行一条底层潜规则：自动将你的 CPU Request 填充为等于 CPU Limit 的值。

后果： K8s 会默默帮你把配置改成 Request: 2, Limit: 2。
这有什么坏处？ 我们前面讨论过，CPU Request 设得太高（比如 2核），会严重吃掉账面调度空间。你可能本来只是想要个上限，结果无意中把 Request 也拉满了，导致大量算力在调度账面上被白白锁定，集群资源利用率暴跌。

架构师总结：为什么“10m”的低保也比“不设”强？

绝对不能让 CPU Request 留空。

哪怕你只给它设置一个极小的值，比如 requests.cpu: 10m 或者 50m，在底层意义上也是天壤之别：

不设置，权重是 2（随时被踩在脚底饿死）。
设置 50m，权重就是 51。虽然不多，但相当于你在这个节点上拿到了合法的“股权”和“最低生活保障”。

当宿主机 CPU 被打爆到 100% 时，这 50m 的 Request 能保证内核依然会硬性切出一小块时间片给你的服务。你的服务处理请求会变慢（比如从 50ms 变成 1s），但绝对不会假死停摆，依然能缓慢但坚定地响应请求。

CPU Limit：建议不设置（Unset）

是否需要设置？ 现代云原生架构强烈建议：不设置（删除该字段）。
为什么？ K8s 的 CPU Limit 依赖 Linux CFS Quota 机制。如果设置了 Limit（例如 2.0），即使宿主机当时有 10 个空闲的 CPU 核心，只要你的服务在 100 毫秒内用完了属于自己的配额，也会被内核强行暂停（Throttling）。这会导致极严重的 P99 延迟毛刺。
结论： 拔掉 CPU 限速器，让应用在突发计算时瞬间借用节点空闲算力秒级处理完毕，是降低延迟的最佳实践。

Memory Request：必须设置，生死攸关

是否应该设置？ 必须设置。 K8s 调度时用来占坑，也是宿主机内存不足时，判定你是否属于“超用资源”并决定驱逐优先级的核心标准。
不设置的话他也是会任意调度到只要有资源的节点，有可能调度上去服务启动不起来。

Memory Limit：必须设置，且策略决定命运

是否应该设置？ 必须设置。 内存不像 CPU，如果没有上限，一行有 Bug 的代码造成的内存泄漏，就能把整台宿主机拖死。
是否要与 Request 相等？ 这里分化出了云原生架构中的两大流派：

两大流派：追求极致稳定 vs 压榨集群资源

在实际生产中，没有绝对的对错，只有业务场景的取舍。请根据你的服务重要等级对号入座：

流派 A：核心保命流（Maximum Stability）

适用场景： 核心交易链路、网关、有状态服务（数据库、中间件）、不支持重试的复杂业务。

配置公式： Memory Request == Memory Limit，CPU Limit 不设置。

原理解析： 当内存的 Request 等于 Limit 时，K8s 会赋予该 Pod 最高的服务质量等级（Guaranteed）。这相当于拿到了免死金牌。
优势： 哪怕同节点的其他服务疯狂吃内存导致宿主机 OOM，K8s 也绝对不会杀你的服务。你的内存边界是极其清晰和确定的。
代价： 会产生“稳定性溢价”。例如你设置了 2G，平时只用 1G，剩下的 1G 在 K8s 调度账面上被永远锁死，造成物理内存的“账面浪费”。

流派 B：极限压榨流（Extreme Cost Squeezing）

适用场景： 无状态 Web 服务、异步计算 Worker、离线跑批任务、可随时安全重启的边缘服务。

配置公式： Memory Request < Memory Limit（例如 Req=500M, Lim=2G），CPU Request 极低，CPU Limit 不设置。

原理解析： 这属于 Burstable（突发性能）级别。账面上只占 500M 调度空间，让节点能塞进几倍数量的 Pod，极大提高装箱率。同时给予 2G 的 Limit，允许服务在突发流量时“借用”节点物理内存。
优势： 极致的降本增效。用最少的机器跑最多的微服务。
代价（风险）： 节点级内存超卖。当多个突发流量重叠时，宿主机物理内存会被瞬间抽干。此时 K8s 会无情驱逐这些 Request < Limit 的 Pod。服务会被频繁杀死重启。

总结与架构师建议

最后，为读者提供一份简单粗暴的速查表：

最佳实践补丁： 如果你选择了“核心保命流”（Req==Lim）又心疼浪费的资源，请不要通过降低 Request 来制造差值，而是应该引入 HPA（水平自动扩缩容）。将单体内存压低，遇到流量洪峰时通过增加 Pod 副本数来抗压，这才是云原生架构“横向扩展”的终极奥义。

突破静态配置的死局：动态扩缩容（HPA & VPA）的底层逻辑

单靠静态设定 Requests 和 Limits，永远无法完美契合业务流量的波峰波谷。云原生真正的威力在于“按需变形”。

HPA (Horizontal Pod Autoscaler) – 横向分流，对抗高并发的终极武器

千万不要试图用单实例的 CPU 或内存极限去硬扛大促峰值，这既危险又昂贵。

它与 Resources 的强绑定关系： HPA 默认是基于资源的利用率触发的（比如 CPU 达到 80%）。注意这里的坑：K8s 计算利用率的公式是 当前真实使用量 / Pod 的 CPU Request。
- 如果你不设置 CPU Request，基于 CPU 的 HPA 将彻底失效，因为分母为 0（无法计算百分比）。
- 如果你把 CPU Request 设得过低（比如 10m），只要流量稍微波动，利用率瞬间飙升到 500%，HPA 会被频繁触发，导致集群产生严重的“扩容抖动”。
架构师建议： 将单 Pod 的 Memory 限制死（Req == Lim），剥夺 CPU Limit，然后将 HPA 的阈值设为 CPU Request 的 70% 或基于并发请求数（如 Knative RPS）进行秒级横向扩容。

VPA (Vertical Pod Autoscaler) – 垂直修正，治疗“拍脑袋配置”的良药

很多时候，开发人员根本不知道自己的 Java 或 Go 程序到底需要多少内存。

它的核心价值： VPA 组件会持续读取历史监控数据，自动帮你计算出最科学的 Requests 和 Limits。
工作模式与痛点：
- Recommend 模式（推荐使用）： 只提供修改建议，不主动干预。你可以结合 CI/CD 流水线，在下次发布时自动应用这些建议。
- Auto 模式（谨慎使用）： 自动修改配置。但在 K8s 1.27 版本之前，修改资源的代价是必须杀掉 Pod 重启。如果核心服务在高峰期被 VPA 重启，那就是人为制造的灾难。（注：K8s 1.27+ 引入了原地扩缩容 In-place Resize，未来这一痛点将被消除）。
冲突警告： 绝对不要在同一个指标（比如 CPU）上同时开启 HPA 和 VPA，它们会互相打架，导致 Pod 数量和单体配额同时疯狂震荡。

架构师的军火库：资源水位探测与超卖神器

明白了理论，落地时我们需要工具。针对你前面担忧的“为了稳定浪费内存（Req==Lim），为了省钱牺牲稳定（Req<Lim）”的死局，目前业界有以下几款顶级开源工具可以破局。

Robusta KRR (Kubernetes Resource Recommender) —— 监控数据的“提纯器”

这正是你之前导数据的工具。它不改变 K8s 的调度底层，而是作为你的“首席精算师”。

核心打法： KRR 从 Prometheus 提取真实历史水位，帮你打破“凭感觉填 YAML”的困境。
解决的问题：
- 它建议你删掉 CPU Limit，直接根除了 CFS Throttling（限流卡顿）问题。
- 它根据 P99 分位值建议你的 Memory Request 和 Limit，让你能够安心地使用 Req == Lim 的策略，把所谓的“浪费（稳定性溢价）”压到最低。
定位： 静态配置优化工具。适合日常巡检、CI/CD 准入拦截。

Koordinator (阿里开源) —— 终极

如果你对那 0.5G 被账面锁死的内存耿耿于怀，Koordinator 是解决这个问题的标准答案。它是阿里双十一大规模混部（Colocation）技术的开源版。

核心打法（QoS 重新定义）： 它绕过了原生的 K8s 调度器，引入了更精细的优先级：
- LS (Latency Sensitive – 在线服务)： 比如你的微服务，要求绝对稳定，设置 Req == Lim == 2G。
- BE (Best Effort – 离线任务)： 比如日志压缩、数据跑批。
它是怎么压榨资源的？ 你的微服务申请了 2G，但平时只用 1G。Koordinator 的底层组件（Koordlet）会实时计算出这 1G 的“真实物理空闲”，然后把这 1G 临时借给 BE 级别的离线任务用。
稳定性兜底（秒级驱逐）： 当你的微服务突然来了流量，需要用到 1.8G 内存时。Koordlet 会在毫秒级反应过来，直接把占用内存的离线任务强杀掉，把物理内存还给你的微服务。
定位： 节点级物理资源压榨器。让“账面资源满载率”和“物理真实利用率”同时达到 80%+，而核心业务毫发无损。

Crane (腾讯开源) —— 具有预知能力的智能调度

如果你的集群跑在腾讯云 TKE 上，或者业务有明显的潮汐特性（比如外卖系统中午流量大），Crane 非常合适。

核心打法（时间序列预测）： 基于历史监控，用算法预测未来 24 小时的流量走势。
解决的问题： HPA 是滞后的（流量打进来了，CPU 飙高了才扩容，此时往往已经卡顿）。Crane 的 EHPA（Effective HPA）可以在高峰期到来前 10 分钟，提前帮你把 Pod 扩容好。
防干扰调度： Crane 会识别出哪些节点物理 CPU 真正到了高水位，从而拦截 K8s 瞎眼调度器的分配请求，防止某些节点被活活拖死。
定位： 智能弹性与成本分析平台。

Goldilocks (Fairwinds) —— 轻量级 Baseline 工具

核心打法： 利用 VPA 的 Recommend 模式，结合一个非常直观的 UI 面板，给你的每一个 Deployment 展示一套推荐的 Request/Limit 基线。
定位： 如果觉得 KRR 的命令行不够直观，可以作为集群可视化的资源推荐补充工具。

终极总结：现代云原生微服务资源配置蓝图

作为集群的管理者，你可以按照以下路径构建你的资源防线：

第一层（配置基线）： 借助 Robusta KRR 或 Goldilocks，为所有服务刷上基于历史数据的 Baseline。核心服务锁死 Mem Req == Mem Lim，拔掉 CPU Limit。
第二层（弹性抗压）： 依托科学的 CPU Request 设定，全面铺开 HPA。用增加副本数来应对突发，而不是靠单 Pod 的内存硬扛。
第三层（极致压榨）： 如果集群规模足够大，机器成本成为痛点，引入 Koordinator。将无状态后台任务与核心微服务混合部署，吃干榨净每一兆物理内存。

前言