在 Kubernetes 中部署服务时，你是否遇到这些问题：
- 容器莫名其妙被重启？
- 节点负载飙升，服务不可用？
- 明明 Pod 没死，却对外响应超慢？
这些问题的罪魁祸首，很可能是你没有正确配置资源限制！
本文将带你深入理解 Kubernetes 的资源限制机制，掌握 CPU 和内存背后的运行逻辑，教你如何合理配置，让服务“稳如老狗”。
一、什么是资源限制？
Kubernetes 提供了两种资源声明机制：
| 类型 | 作用 |
|---|---|
requests | 最低保证值，调度依据 |
limits | 最大限制值，超出将被限制或终止 |
举个例子👇：
resources:
requests:
cpu: "500m"
memory: "256Mi"
limits:
cpu: "1"
memory: "512Mi"
- 表示该容器启动时会被调度到 至少有 0.5 核和 256Mi 内存 的节点；
- 运行时最多使用 1 核 CPU 和 512Mi 内存；
- 超出 CPU，会被限速；
- 超出内存，会被杀掉（OOMKilled）！
二、CPU 与内存限制的底层行为差异
✅ CPU：可以超用，但会被限速
- 超过
requests.cpu：允许，但不能抢占其他 Pod； - 超过
limits.cpu：被 cgroup 限速（比如用cpulimit限制带宽）； - 限速表现为：响应变慢、处理延迟上升，但不会直接被杀死。
❌ 内存：绝不宽容，超限就杀
- 超过
requests.memory：不会影响运行； - 超过
limits.memory：直接被 K8s 判定为 OOM，系统会无情 kill 掉你的容器！
这就是为什么你经常看到容器突然崩掉，状态变成：
Last State: Terminated
Reason: OOMKilled
三、实战配置建议
场景一：稳定优先的核心服务
resources:
requests:
cpu: "1"
memory: "1Gi"
limits:
cpu: "1"
memory: "1Gi"
- 限制 = 请求，保障稳定性；
- 推荐用于数据库、支付、鉴权等核心模块。
场景二：弹性伸缩的业务服务
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "2"
memory: "1Gi"
- 允许突发，节约资源；
- 建议与 HPA（自动伸缩）配合使用。
场景三：开发环境 or 灰度发布
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "200m"
memory: "256Mi"
- 限制较小，节省资源；
- 若服务重要性不高，可适当放宽资源限制。
四、如何排查资源问题？
1️⃣ 查看 Pod 状态
kubectl describe pod <pod-name>
检查 Events 区域是否有：
OOMKilled
Back-off restarting failed container
2️⃣ 使用监控工具（Prometheus + Grafana）
观察 CPU 使用率、内存水位线，判断资源瓶颈。
3️⃣ 启用 LimitRange 和 ResourceQuota
防止开发人员部署未限资源的服务导致节点爆炸。
五、常见误区警示 🚫
| 误区 | 正解 |
|---|---|
| 不设 limits，就不会被限制 | 可能会拖垮整个节点！ |
| limits 越高越好，防止服务卡死 | 会导致资源浪费，调度失败 |
| requests 设得太低无所谓 | 会被调度到“边角料”节点，性能不可控 |
| 内存用不完自动释放 | 应用要主动释放，K8s 不会“帮你清理” |
六、最佳实践总结
✅ 设置合理的 requests，保障调度可控性；
✅ 设置合理的 limits，防止单服务资源爆炸；
✅ CPU 要留有余地，防止服务抖动；
✅ 内存一定要充足，避免 OOM 一击致命；
✅ 配合自动伸缩（HPA）实现资源弹性利用；
✅ 定期通过监控回顾真实资源使用情况，持续优化。
七、结语：你不给限制，K8s就给你“惊喜”
很多系统奔溃事故的根源，不是技术不行，而是忽略了最基本的资源边界控制。
资源限制不是限制服务，而是保护服务！
现在就回去看看你的 Pod 配置，别让一个小小的 OOMKilled，毁掉你的高可用！
