做菜讲究火候和分量，厨房里每个灶台能同时开几个炉子是有限的。你不可能在一个小厨房里同时炒十个菜，不然灶不够用，油烟满屋，饭也做砸了。这跟管理 ref="/tag/2020/" style="color:#C468A7;font-weight:bold;">Kubernetes 集群挺像——集群里的 CPU 和内存就像灶台和火力，资源就那么多，不设限的话，一个应用“猛火快炒”起来，别的服务就得等着挨饿。
为啥要给容器“定灶台”？
在公司测试环境里，开发小李部署了个新服务，没设资源限制，结果这服务一启动就开始疯狂吃内存，像个不知节制的厨师占着所有灶台炖大锅肉。没过多久，数据库服务因为拿不到资源直接卡死，线上订单都下不了。这种事儿在厨房叫“抢灶”，在 K8s 里叫“资源饥饿”。
Kubernetes 允许你在 Pod 的配置里明确指定每个容器最多能用多少 CPU 和内存，就像规定每道菜只能用一个灶眼、最多炖两小时。这样即使有人写了个“贪吃”的程序，也不会把整个集群搞崩。
怎么写这个“厨房守则”？
在 Deployment 或 Pod 的 YAML 里，加个 resources 字段就行。比如你想让一个服务最多用 500 毫核 CPU 和 512MB 内存，可以这么写：
resources:
limits:
cpu: "500m"
memory: "512Mi"
requests:
cpu: "200m"
memory: "256Mi"这里的 requests 是它启动时申请的基本灶位，limits 是它最多能霸占的上限。Kubelet 会按这个规则调度，就像厨房班长安排谁用哪个灶。
实际场景：别让“汤锅溢出”拖垮全家
有次运维老张发现集群总有节点突然变慢，查了一圈发现是个日志收集器在特定时间疯狂增长内存使用。原来日志量一大，它没设 limit，直接把宿主机内存撑爆，连带着跑在同一节点上的支付服务都超时。后来加上内存限制后，一旦超限容器就被系统干掉重启，虽然它自己“翻车”，但至少没把整桌宴席都弄砸。
就像煮汤时不能把锅倒满就不管，得留点空间防溢出。容器也得留余地，一般建议 limit 设置成 requests 的 1.5 到 2 倍，既保证弹性，又不至于失控。
用命名空间划好“厨房分区”
大公司里不同团队共用一个集群，就像食堂里多个班组共用厨房。这时候可以用 Namespace 配合 ResourceQuota，给每个团队划定量的资源总额。比如前端组每月最多用 8 核 CPU 和 16G 内存，用超了再提交新菜谱（Pod）就会被拒。
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-quota
namespace: frontend-team
spec:
hard:
requests.cpu: "8"
requests.memory: "16Gi"
limits.cpu: "16"
limits.memory: "32Gi"这样一来，谁也不能偷偷加灶，厨房秩序就稳了。
管集群不像写代码那样非黑即白，更像掌勺，得凭经验、看火候。设置合理的资源限制，不是为了卡死灵活性，而是让整个系统能安稳运转，谁都能按时吃上饭。