Kubernetes资源配额LimitRange与ResourceQuota分级管控实践

Kubernetes资源管控的分层设计思路

Kubernetes集群的多租户资源管控是运维稳定性的核心问题。没有资源限制的容器可以无节制地消耗节点CPU和内存，导致OOM Killer误杀相邻Pod、CPU throttling引发全局延迟抖动。Kubernetes提供了ResourceQuota（命名空间级总量控制）和LimitRange（Pod/Container级默认值与上下限）两级管控机制，两者配合才能构建完整的资源防护体系。

ResourceQuota限制命名空间的资源总量上限，防止一个团队占用整个集群；LimitRange则为该命名空间内的每个容器设定默认值和合法范围，确保即使开发者未指定resources字段，容器也不会以unbounded状态运行。两级机制缺一不可：只有ResourceQuota，开发者可以提交任意大的requests绕过总量上限；只有LimitRange，单个命名空间的资源总量无法约束。

LimitRange配置：默认值与合法范围

LimitRange为容器和Pod设置默认资源请求/上限，以及合法的范围约束：

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: team-alpha
spec:
  limits:
  - type: Container
    default:
      cpu: "1"
      memory: "512Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"
    max:
      cpu: "4"
      memory: "4Gi"
    min:
      cpu: "50m"
      memory: "64Mi"
    maxLimitRequestRatio:
      cpu: "5"
      memory: "3"
  - type: Pod
    max:
      cpu: "8"
      memory: "8Gi"

关键字段说明：

default/defaultRequest：当Pod清单未指定resources时自动注入，这是防止unbounded容器的核心防线。
maxLimitRequestRatio：限制limit与request的比例，防止开发者设置极低request配超高limit，避免调度时节点过度承诺。CPU比率5倍意味着request 100m的容器最多配limit 500m。

ResourceQuota配置：命名空间总量管控

ResourceQuota从命名空间维度约束资源总量，支持计算资源、存储资源、对象数量三类配额：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "16"
    requests.memory: "32Gi"
    limits.cpu: "32"
    limits.memory: "64Gi"
    requests.storage: "500Gi"
    persistentvolumeclaims: "20"
    pods: "50"
    services: "10"
    secrets: "30"
    configmaps: "30"

ResourceQuota的生效前提是命名空间内的所有容器都必须显式指定requests和limits，否则准入控制器会拒绝创建。这正是LimitRange提供default值的意义——两者配合形成闭环。

多租户分级管控实践

生产环境通常按团队或项目划分命名空间，每个命名空间配置不同的配额等级：

# 核心业务命名空间 - 高配额
apiVersion: v1
kind: ResourceQuota
metadata:
  name: core-quota
  namespace: core-business
spec:
  hard:
    requests.cpu: "64"
    requests.memory: "128Gi"
    pods: "200"
---
# 测试环境命名空间 - 低配额
apiVersion: v1
kind: ResourceQuota
metadata:
  name: test-quota
  namespace: team-test
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "16Gi"
    pods: "30"

配额等级的设定应基于集群总资源和SLA优先级。核心业务命名空间获得集群60%以上资源保障，测试环境限制在15%以内，剩余资源作为弹性空间。配合PriorityClass和preemption机制，核心业务Pod在资源紧张时可抢占低优先级Pod。

配额超限的监控与告警

ResourceQuota的使用率需要实时监控，避免命名空间在配额即将耗尽时才发现：

# Prometheus查询配额使用率
# CPU request使用率
100 * kube_resourcequota_used{resource="requests.cpu", namespace="team-alpha"}
  / kube_resourcequota_hard{resource="requests.cpu", namespace="team-alpha"}

# 内存limit使用率
100 * kube_resourcequota_used{resource="limits.memory", namespace="team-alpha"}
  / kube_resourcequota_hard{resource="limits.memory", namespace="team-alpha"}

告警规则设置：CPU request使用率超过80%触发Warning，超过95%触发Critical。内存告警阈值同理。使用Grafana的Stat Panel可以为每个命名空间展示配额使用率热力图，快速定位资源瓶颈。

常见问题与排障

1. Pod创建报错exceeded quota：查看命名空间ResourceQuota的used值与hard值，确认是哪项资源超限。缩减已有Pod的requests或申请提升配额。

2. LimitRange未生效：检查Pod是否已在LimitRange创建前提交（LimitRange不追溯已有Pod），以及LimitRange的type是否匹配（Container/Pod/PVC）。

3. maxLimitRequestRatio配置后Pod无法创建：确认Pod清单中limit/request比例不超过设定值。Java应用常见问题是Xmx远大于request memory，需调整JVM堆大小与容器request对齐。

4. 配额与集群自动扩缩容冲突：命名空间配额硬限制会导致HPA扩容失败。建议为HPA管理的Deployment预留20%配额余量，或使用ClusterAutoscaler配合配额管理。