给容器集群配置资源配额，核心思路是两层卡口：namespace层用ResourceQuota锁死配额池，Pod层用LimitRange锁死单个应用的申请上限，再配合HPA和驱逐策略做兜底，单应用最多吃掉自己那份，碰不到别人的蛋糕。
先弄明白单应用是怎么把集群吃满的
很多团队不是没配配额，而是配了形同虚设，比如只设置了request没设置limit，或者只设置了CPU没设置内存，结果一个业务高峰期，某个服务的Pod疯狂申请内存，节点内存被打穿，kubelet的驱逐循环开始干活，一堆Pod被反复杀死重启，整个集群陷入“雪崩式恢复”的怪圈。
这里要分清一个底层机制：CPU是可压缩资源，Pod可以排队等调度，顶多性能变差，不会死；内存是不可压缩资源，申请不到就OOM，内核直接杀进程，容器云资源池管理最怕的就是这种不可压缩资源的失控，一旦节点内存耗尽，受害的不只是肇事Pod，还有同节点上其他无辜Pod，行业共识认为，给内存设limit比给CPU设limit紧迫得多,这是生产环境资源管控的第一课。
有些团队还踩过另一个坑：只配了ResourceQuota没配LimitRange，ResourceQuota管的是总量，LimitRange管的是单量，这两个缺一个都不行,后面具体展开说。
k8s资源配额怎么设置，才能从根上防住单应用吃满集群
设置的核心不是堆一堆yaml文件，而是要建立一条“命名空间 → 配额 → 单Pod限额 → 自动伸缩”的链路，这条链路每一环都有明确职责,缺一环就漏一个方向。
第一环：用ResourceQuota做命名空间的硬顶
ResourceQuota控制的是一个namespace内所有Pod的资源总和上限，相当于一个“总量天花板”，没有它，即使每个Pod都写了limit，业务方也可以无限扩容,最后还是把整个集群的资源吃掉。
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota-team-a
namespace: team-a
spec:
hard:
requests.cpu: "20"
requests.memory: 40Gi
limits.cpu: "40"
limits.memory: 80Gi
pods: "50"
这里可以看到，requests和limits要分开设，requests保障的是基线资源，limits是封顶资源。两者之间的差值就是超卖空间，比如requests.memory设40Gi，limits.memory设80Gi，意味着允许业务方在突发时报高一点,但总量不能超过80Gi。
第二环：用LimitRange堵住单Pod无限制申请的口子
ResourceQuota锁住总量之后，真正的压力测试才刚开始，假设namespace里还能再创建10个Pod，每个Pod的limits.memory直接写20Gi，那会发生什么？没错，10个Pod就能把80Gi配额吃干抹净,所以单Pod的限额必须用LimitRange来卡。
apiVersion: v1 kind: LimitRange metadata: name: limitrange-team-a namespace: team-a spec: limits: - max: cpu: "4" memory: 8Gi min: cpu: 100m memory: 128Mi default: cpu: 500m memory: 1Gi defaultRequest: cpu: 200m memory: 512Mi type: Container
这个配置的意思很直白：这个namespace里的任何容器，内存最大8Gi、最小128Mi，没写resources字段的容器自动套用default值，最巧妙的是这个default机制业务方即使不写resources，系统也会替它写一个默认值，彻底堵住了“我忘配了”的漏洞。
第三环：HPA跟配额要协同调参
集群里的HPA（Horizontal Pod Autoscaler）如果只配置了CPU使用率50%就扩容，而配额里pods字段限制50个，那业务方会在某次流量波峰看到“replica不增反降”的怪象，因为配额已经被占满了，建议把HPA的maxReplicas跟ResourceQuota的pods数量做一次联动校验，确保maxReplicas × 单Pod的limits < namespace的limits配额总量。
核心链路可以用表格来理解：
| 层级 | 控制对象 | 典型问题 | 解决手段 |
|---|---|---|---|
| Node节点 | 节点总资源 | 节点内存打穿 | kubelet驱逐策略、system-reserved |
| Namespace | 总量配额 | 某团队扩满所有容量 | ResourceQuota |
| Pod/Container | 单实例限额 | 单Pod无限申请资源 | LimitRange |
| Pod调度 | QoS等级 | 驱逐顺序不可控 | 设置requests/limits比例 |
kubernetes命名空间限额配置在真实场景里的三个大坑
坑一：LimitRange只配了max没配default，业务方直接被拒
有的团队图省事，LimitRange里只写了max和min，但没写default和defaultRequest，结果新Pod创建的时候，因为Pod模板里没写resources字段，被准入控制器直接拒绝，报错信息长长一串，前端一脸懵。原因就是LimitRange的两个default字段承担“默认注入”职责，缺了它，所有不带resources的Pod都会被当成非法请求拦截，排查起来也简单：用kubectl describe limitrange -n 你的命名空间查看有没有Limits and Requests列缺属性,缺了就补上。
坑二：Java应用在容器里看不见自己被困住了
Java的JVM默认堆大小是按物理机内存计算的，不是按容器cgroup的限额计算，如果容器limit是2Gi，但物理机有64Gi内存，JVM启动时可能认为自己能堆到16Gi，结果业务一上来，堆内存往上涨，触碰容器memory limit，Pod直接被杀。这不是配额没配，而是配额配了但业务方没有感知，业内专家指出，Java应用进容器必须显式设置
-XX:MaxRAMPercentage或-Xmx参数，且要跟limit值留出至少25%的余量给元空间和线程栈，这个问题在Java 10之前尤其突出，现在即便新版JDK默认感知cgroup，也建议显式写,因为某些运行时的内存池开销仍然算不到JVM堆头上。
坑三：CPU配额给了，但业务反而变慢了
现象很典型：某服务CPU的limit是4核，但总把4核用满，接口RT飙升，业务方来找你说“你给的限制太少了”，真相是，单实例的CPU limit上限设得太低，同时HPA的扩容阈值又设得太缓，流量一来实例数涨不上去，每个实例又饿着肚子干活,排查步骤可以照着做一遍：
kubectl top pod -n 你的命名空间，看每个Pod的真实CPU和内存用量kubectl describe pod 你的Pod名称，看Events里有没有ThresholdCrossed或OOMKilled记录- 对比实时用量和limit的比值，如果持续超过80%，则考虑提高limit或调整HPA的扩容步长
生产环境的资源配额设计，得按“多层缓冲”来
只有配额本身还不够，生产环境里真正考验人的是“配额怎么分配才合理”，直接照抄网上模板很容易出问题毕竟是自家业务形态说了算,比较稳妥的设计分三层：
第一层：环境级隔离
开发、测试、预发、生产各自独立集群，如果资源紧张只能共用集群，也要用强隔离策略：每个环境独立namespace，namespace上再挂独立的ResourceQuota。不能出现生产环境和预发环境共用同一个配额池，不然流量高峰的时候，预发的大批量压测Pod就能把生产环境资源挤占掉，比较合理的做法是给生产环境配额池预留总集群资源的60%以上,让非生产环境的可用资源形成天然屏障。
第二层：业务级分类
按业务属性把namespace分成三类：
- 核心支付链路：配置Guaranteed的QoS等级，也就是requests等于limits，不允许超卖
- 常规在线业务：Burstable等级，requests小于limits，允许资源复用
- 离线任务/计算任务：BestEffort等级，优先被驱逐
这样配置之后，单个应用吃满的后果只局限在它自己的等级池里，比如离线任务全部吃满，只会驱逐自己,不会动到在线业务。
第三层：突发流量兜底
配额池再满，也得留出一点缓冲空间，建议在每个namespace的ResourceQuota里只配到总可行容量的80%，剩余20%留给node级别的system-reserved和kube-reserved。凡是追求100%资源利用率的生产集群，一定会在某个深夜为这个决定买单，因为节点的系统进程、日志采集、网络插件也需要资源,完全打满会被系统组件反噬。
配完配额之后的监控水位线，决定你到底稳不稳
配额配好不代表万事大吉。配额解决的是“能不能吃”的问题，监控解决的是“吃了多少”的问题,两者缺一不可。
需要重点盯三个指标：
- 配额使用率：
kubectl get resourcequota -n 你的命名空间，看usage和hard的比例，超过70%就要准备扩容或者清理闲置资源 - Pod驱逐次数：集群事件里出现
SystemOOM或Evicted关键字要警惕，证明某个节点的水位接近临界线 - 真实容器内存水位：用metrics-server或Prometheus看container_memory_working_set_bytes，防止业务“申请了但不用，另一个业务想用却进不来”的浪费
建议每个月做一次配额回顾：找出usage长期小于50%的namespace，收回一部分配额池调到更需要的业务侧；同时找出usage反复撞顶的namespace，去内部看是不是某个应用存在内存泄漏或者扩容策略不合理。
本身：给容器集群配置资源配额防止单应用吃满，解法和汽车的安全带一个道理，关键不在于“绑了没有”，而在于“绑在了正确的位置、松紧调到了正确的尺度”，ResourceQuota定总量，LimitRange定单量，HPA定弹性，监控定调优这四件套齐全之后,再浪的业务也翻不出你的五指山。
容器集群资源配额与单应用占用相关的三个高频问题
问：k8s资源配额怎么设置才能不影响正常的业务扩容？
答：把ResourceQuota的limits总量设置成实际可分配容量的80%，HPA的maxReplicas设置成达到这个上限即可，同时对业务方的Deployment强制要求设置resources字段，不设就由LimitRange的default自动注入，要注意requests和limits的比例，通常控制在1:1.5到1:2之间，这样扩容既能反应及时,又不会超卖过多造成节点风险。
问：LimitRange配置错误会导致什么现象？
答：最常见的现象是创建Pod被拒，报错CPU or memory range not valid或limitrange default resource values were not found，另一种情况是配置了max但没配default，Pod里没显式写resources的容器会被准入控制器拦截，配置完LimitRange后用kubectl apply -f验证后，再用kubectl get limitrange -o yaml检查所有字段是否生效即可。
问：为什么有时Pod内存没超limit还是被驱逐？
答：节点上所有Pod的实际内存总和超过了节点的allocatable内存，触发kubelet的节点压力驱逐机制，此时驱逐顺序按QoS等级从低到高来，BestEffort的Pod最先被驱逐，即使它单Pod没超过自己的limit，另外一种情况是cgroup的memory阈值与kubelet的驱逐阈值之间存在细微差别,节点PSI和memcg回收延迟也会提前触发驱逐信号。