Kubernetes资源配额：CPU与内存限制范围

先搞懂CPU与内存配额的限制范围

在Kubernetes中，资源管理明确划分为容器/Pod级别与命名空间级别。容器级别的resources.requests表示调度器在分配节点资源时的最低保障值，而resources.limits则是容器运行时的硬性上限，超出内存限制将触发OOM Kill，超出CPU限制则会被CFS调度器节流。当引入命名空间级别的ResourceQuota时，系统会实时统计该命名空间下所有活跃Pod的requests与limits总和，确保整体消耗不超过预设阈值。具体而言，requests.cpu与requests.memory统计的是调度承诺量，limits.cpu与limits.memory统计的是运行上限总量。CPU单位支持整数（如1代表1核）或毫核（如500m代表0.5核），内存单位强烈推荐使用二进制后缀如Mi或Gi，避免与厂商十进制单位产生计算偏差。清晰区分这两层作用域是构建稳定集群资源模型的前提。

配置Namespace的CPU与内存ResourceQuota

配置命名空间资源配额需创建ResourceQuota对象，核心逻辑是在spec.hard字段中明确定义各项资源的硬性上限。典型YAML配置中，可设置requests.cpu为4、requests.memory为8Gi、limits.cpu为8、limits.memory为16Gi。该配置严格限定于目标命名空间，不会横向影响其他业务空间。配额一旦通过kubectl apply生效，任何在该命名空间内新建或更新的Pod，其所有容器声明的requests与limits累加值必须严格小于或等于配额剩余量。若新Pod声明的资源加上当前已分配资源超出hard限制，API Server会在准入阶段直接拦截创建请求。因此，在业务上线前必须结合历史监控数据与扩容预案合理评估配额水位，避免因配额设置过紧导致服务无法弹性伸缩。

验证配额使用量并排查超限问题

配额部署后，可通过kubectl get resourcequota -n <namespace>快速查看当前命名空间的配额状态，终端输出会清晰展示HARD（上限）与USED（已用）两列数据。若需深入定位，执行kubectl describe resourcequota <name> -n <namespace>可获取按资源类型拆分的详细使用明细。当业务尝试部署新Pod时，若USED值加上本次请求的资源量超过HARD值，API Server会拦截请求并返回Forbidden: exceeded quota错误（HTTP 403）。例如，某命名空间内存limits配额为8Gi，已使用7.5Gi，此时尝试部署一个声明limits.memory: 1Gi的Pod，系统将直接拒绝并提示exceeded quota: compute-resources, requested: limits.memory=1Gi, used: limits.memory=7.5Gi, limited: limits.memory=8Gi。排查此类问题时，应优先核对USED字段，确认是僵尸Pod未清理、副本数过多还是单次声明过大，进而通过清理无用资源或调整YAML声明恢复部署。

常见坑：ResourceQuota与LimitRange不要混淆

许多运维人员容易将ResourceQuota与LimitRange混为一谈。ResourceQuota负责管控整个命名空间的资源总量，属于宏观预算池；而LimitRange则作用于单个Pod或容器，用于设置默认值、最小值与最大值，属于微观约束器。启用CPU与内存配额后，Kubernetes会强制要求Pod必须显式声明requests和limits，否则API Server将直接拒绝创建，导致大量未配置资源的Pod持续处于Pending或Failed状态。为规避此坑，强烈建议在同一命名空间内组合使用两者：先通过LimitRange为未声明资源的容器自动注入合理的默认requests/limits，再用ResourceQuota划定命名空间总水位。例如，配置LimitRange默认requests.cpu为100m、limits.cpu为200m，既能保证配额统计有值可依，又能防止个别容器无限制抢占资源，实现宏观总量控制与微观个体约束的无缝协同。