为啥要给容器设限
你家路由器能同时连十几台设备，但要是有人偷偷下高清电影，其他人刷网页都卡成幻灯片。容器也一样，不加限制的话，某个应用疯狂吃内存或CPU，其他服务就得陪它一起瘫痪。
在Kubernetes或Docker里，默认情况下容器能用多少资源全看宿主机还剩多少。这就像合租房子没装独立电表，谁开空调谁烧热水都没数，月底电费肯定扯皮。
怎么给容器“装电表”
Docker启动时可以用--memory和--cpus指定上限。比如这台机器总共4核8G，你想让某个Node.js服务最多用1核和512M内存，就这么写：
docker run -d --name api-service \
--memory=512m \
--cpus=1.0 \
my-api-image这样就算代码里有个死循环拼命申请内存，也不会把整台机器搞挂。到极限时，系统会直接杀掉这个容器的进程，留其他服务正常跑。
Kubernetes里的玩法更细
在YAML文件里可以分别设置requests（保证最低用量）和limits（绝对上限）。比如下面这段配置：
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"意思是：调度时优先安排有至少256M内存和0.25核CPU的节点；运行时最多只能用到512M和0.5核。超过limits会被限速甚至终止。
实际踩过的坑
之前团队上线了个Python数据处理脚本，本地测试好好的，一上生产就把节点内存耗光了。查日志发现是加载大文件时没分块读取，一口气往内存塞了3个G。后来加上内存限制后，容器直接OOM被重启，反而暴露了问题。
还有一次前端构建镜像忘了设CPU限制，CI流程一跑起来占满CPU，导致同节点的数据库响应延迟飙升。现在所有CI任务都强制加上--cpus=2.0，留出余量给线上服务。
监控比设限更重要
光设数字不够，得持续观察真实使用情况。比如用Prometheus抓取各容器的内存曲线，发现某个Java应用长期只用300M，但峰值会冲到480M，那你设512M刚好，设太小可能误杀，设太大又浪费。
资源限制不是一次性配置，更像是动态调优的过程。新服务刚上线可以宽松点，等跑几天看监控数据再逐步收紧，找到性能和安全的平衡点。