上周三下午三点，市场部李经理的电话像炸雷一样打进技术总监王总的办公室：“我们刚上线的电商小程序支付页面打不开了！用户都在投诉！”王总心里一沉——这已经是本周第三次服务崩溃了。作为一家专注于小程序开发、网站开发的软件开发公司，他们最近刚完成三个定制开发项目的容器化部署，本以为能提升效率，没想到却陷入了资源争抢的泥潭。
决策者的“钱袋子”困境：资源浪费vs服务崩溃
王总召集运维团队紧急开会，发现问题出在容器资源没有设置配额。三个项目——电商小程序、企业官网和内部CRM系统——都运行在同一集群里，其中CRM系统因为数据同步任务突然占用了80%的CPU资源，直接导致小程序和官网的服务响应超时。
作为决策者，王总面临的第一个难题是：“到底给每个容器分配多少资源才合适？”给少了怕服务崩溃影响业务，给多了又会造成资源浪费，增加云服务器成本。这就像给员工分配办公室——太小了挤得难受，太大了又浪费租金。对于企业开发来说，资源配额的设置直接关系到成本和用户体验的平衡。
配额配置的“ Goldilocks 原则”：不多不少刚刚好
运维主管张工给出了解决方案：给每个容器设置CPU和内存的“请求”（Request）和“限制”（Limit）。Request是容器运行所需的最小资源，Limit是容器能使用的最大资源。比如，他们给电商小程序设置了0.5核CPU请求和1核限制，内存请求512MB和1GB限制；官网设置0.3核请求和0.8核限制；CRM系统则设置1核请求和2核限制。
CPU配额：避免“饿死”与“撑死”
CPU是可压缩资源，当容器超过Limit时，Kubernetes会对其进行“节流”（Throttle），降低它的CPU使用率。但如果Request设置过低，容器可能会因为得不到足够的CPU而“饿死”，响应变慢。张工举了个例子：“就像高速公路上的车道，Request是你必须占有的车道，Limit是你最多能占的车道。如果大家都不遵守规则乱占道，整个交通就会瘫痪。”
内存配额：防止“溢出”与“泄漏”
内存是不可压缩资源，当容器使用的内存超过Limit时，Kubernetes会直接杀死这个容器（OOMKilled）。因此，内存Limit的设置必须谨慎。张工建议：“先通过监控工具收集一周的内存使用数据，然后在峰值基础上增加20%作为Limit，Request则设置为峰值的50%左右。”这样既保证了容器有足够的内存运行，又防止了内存泄漏导致的集群崩溃。
动态调整的“智慧大脑”：从被动救火到主动预警
设置好初始配额后，王总还要求团队建立动态调整机制。他们用Prometheus监控每个容器的资源使用情况，当某个容器的CPU使用率连续10分钟超过Limit的80%时，系统会自动发送警报给运维人员。对于电商小程序这样的流量波动大的应用，他们还配置了HPA（Horizontal Pod Autoscaler），根据CPU使用率自动增加或减少容器数量。