K8s 里 Pod 的 CPU limits 到底要不要设？我见过三种流派，各有翻车现场

【背景】 我们团队管着 3 个 K8s 集群（阿里云 ACK、自建 3 节点、客户私有化），200+ 微服务。过去两年，「CPU limits 到底设不设」在三次架构评审里被反复吵，每次结论都不一样。今天想把它摊开，听听大家真实生产里的做法。

【三种流派，都有真实场景】

1. 全设派：CPU 和 memory 都设 limits。理由：防止突发流量把节点打爆，邻居 Pod 被连带拖垮。我们一个金融客户的生产集群就走这条，安全基线明确要求「任何容器不得无上限消耗节点资源」。翻车现场：一次大促，某个批处理任务 CPU 飙到 limit 被 CFS quota throttle，P99 从 80ms 抖到 2.3s，但 OOMKill 一个都没发生——因为 memory 有 headroom。

2. 只设 memory、CPU 只设 requests 派：CPU 可压缩，限了只会 throttle（表现为延迟抖动），而 memory 不可压缩，不设 limits 等于把 OOMKill 交给内核，且 SIGKILL 没有 preStop、没有 grace period。Kubernetes 官方文档和 CNCF 社区主流观点都倾向这个方向。翻车现场：我们一个电商客户去掉 CPU limits 后，HPA 盯 CPU utilization（相对 requests），一个 requests=200m 的 Pod 跑到 800m 就是 400%，HPA 疯狂扩副本，但每个副本的延迟其实没恶化（CPU 可压缩，只是变慢）——扩了 6 个副本，资源浪费 3 倍。

3. 都不设 limits、靠弹性兜底派：只设 requests，靠 HPA + cluster-autoscaler 兜底。理由：limits 是「事后补救」，真正该做的是让容量规划跟得上。我们一个做实时风控的客户走这条，节点池配了 autoscaler，limits 全去掉后 P99 反而更稳（因为彻底消除了 throttle 抖动）。翻车现场：一次 autoscaler 响应延迟（新节点拉镜像 + 调度 40s），期间一个内存泄漏的 Pod 把节点吃满，连带 3 个邻居被 OOMKill。

【我的倾向与理由】 我目前站「只设 memory、CPU 只设 requests」，但有一个关键前提：HPA 的 metrics 不能是 CPU utilization。

• 如果 HPA 盯自定义 metrics（QPS、队列深度、gRPC 并发数），那 CPU limits 的存在意义就很小——扩容信号来自业务负载而非 CPU 占用，throttle 只影响单 Pod 延迟，不会误导扩容。
• 如果 HPA 盯 CPU utilization（相对 requests），那去掉 CPU limits 后，「CPU 可压缩」这个特性会让 utilization 虚高（Pod 实际在正常工作，只是慢了一点），HPA 误判扩副本，资源浪费。
• memory 我坚持要设 limits：OOMKill 是 SIGKILL，没有优雅退出机会。设 limits 至少让 kubelet 在 OOM 之前有机会走驱逐流程（eviction），而不是内核直接杀。

【想听大家在什么场景下怎么选】

• 你们生产集群 CPU limits 到底设不设？如果设，是按多少倍 requests 设的（1x / 2x / 4x）？
• HPA 的 metrics 用 CPU utilization 还是自定义 metrics？这两者怎么配合？
• 有没有「设了 CPU limits 反而翻车」的真实案例？throttle 导致的 P99 抖动你们怎么观测的（node_exporter 的 cpu.cfs_throttled？还是只看应用侧延迟）？
• memory limits 你们设不设？如果设，给多少 headroom？
• 有没有试过「完全不设 limits」的？autoscaler 响应延迟窗口里你们怎么兜底？

欢迎贴出你们的 YAML、HPA 配置、事故时间线，比抽象讨论有营养得多。