Kubernetes资源配额与LimitRange实战：多租户集群资源隔离方案

多租户Kubernetes集群为何需要资源配额管理

在共享Kubernetes集群中运行多个业务团队的工作负载时，如果没有资源配额约束，一个团队的Pod可能消耗掉整个节点的CPU和内存，导致其他团队的服务因资源不足而无法调度或被OOMKilled。资源配额（ResourceQuota）和限制范围（LimitRange）是Kubernetes原生提供的多租户资源隔离机制，配合命名空间使用，可以实现精细化的资源分配和管控。这一方案在DevOps实践中是保障集群稳定性的基础配置。

ResourceQuota：命名空间级资源总量控制

ResourceQuota限制一个命名空间中所有Pod的资源总量上限，防止某个命名空间占用过多集群资源：

# team-a命名空间的资源配额
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    # CPU和内存总量限制
    requests.cpu: "32"
    requests.memory: 64Gi
    limits.cpu: "48"
    limits.memory: 96Gi
    # 对象数量限制
    pods: "50"
    services: "10"
    persistentvolumeclaims: "20"
    configmaps: "50"
    secrets: "50"
    # 存储配额
    requests.storage: "500Gi"
    # GPU资源（如果集群有GPU节点）
    requests.nvidia.com/gpu: "4"

上面的配额定义了team-a命名空间最多可以使用32核CPU请求、64Gi内存请求，最多运行50个Pod。当该命名空间的资源使用量达到上限时，新创建的Pod将被拒绝调度。

LimitRange：Pod和容器级资源边界约束

ResourceQuota控制总量，LimitRange控制单个Pod或容器的资源范围。没有LimitRange，用户可以创建一个请求极少资源但限制极高资源的Pod，绕过ResourceQuota的约束：

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

关键字段说明：

– default：当Pod未指定limits时使用的默认值
– defaultRequest：当Pod未指定requests时使用的默认值
– maxLimitRequestRatio：limits与requests的最大比值，防止请求资源过少但限制过高的情况。设为4意味着limits最多是requests的4倍

资源配额监控与告警

仅配置配额不够，需要持续监控资源使用率，在接近配额上限时及时告警：

# 查看命名空间资源配额使用情况
kubectl get resourcequota -n team-a -o yaml

# 输出示例：
# spec.hard.requests.cpu: "32"
# status.hard.requests.cpu: "32"
# status.used.requests.cpu: "28"   # 已使用28核，接近上限

# 使用Prometheus监控配额使用率
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: resource-quota-alerts
  namespace: monitoring
spec:
  groups:
  - name: resource-quota
    rules:
    - alert: ResourceQuotaNearExhaustion
      expr: |
        kube_resourcequota{type="used"} 
          / on(namespace, resourcequota) kube_resourcequota{type="hard"}
          > 0.85
      for: 10m
      labels:
        severity: warning
      annotations:
        summary: "命名空间资源使用超过85%"

多租户资源分配的工程实践

在生产环境中，资源配额管理需要配合多个配套策略才能有效运转：

1. 命名空间标准化创建流程
每个团队分配独立的命名空间，创建时自动注入ResourceQuota和LimitRange：

# 团队入驻模板
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: team-\${TEAM_NAME}
  labels:
    env: \${ENV}
    owner: \${TEAM_NAME}
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: \${TEAM_NAME}-quota
  namespace: team-\${TEAM_NAME}
spec:
  hard:
    requests.cpu: "\${CPU_QUOTA}"
    requests.memory: "\${MEM_QUOTA}Gi"
    pods: "\${POD_LIMIT}"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: \${TEAM_NAME}-limits
  namespace: team-\${TEAM_NAME}
spec:
  limits:
  - type: Container
    max:
      cpu: "4"
      memory: 8Gi
    default:
      cpu: "1"
      memory: 512Mi
    defaultRequest:
      cpu: 100m
      memory: 128Mi
EOF

2. 配额申请与审批流程
当团队资源使用接近配额上限时，不应直接修改配额，而是走审批流程：团队提交扩容申请（含业务增长数据支撑），运维评估集群总资源后决定是否批准扩容以及扩容幅度。

3. 优先级与抢占机制
在集群资源紧张时，通过Pod优先级和抢占机制保障高优先级工作负载的运行：

# 定义优先级类
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
preemptionPolicy: PreemptLowerPriority
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: low-priority
value: 100000
globalDefault: true
preemptionPolicy: PreemptLowerPriority

4. 定期配额审计
每月对各命名空间的实际资源使用率和配额分配进行审计，回收长期未使用的配额，避免资源浪费。

常见问题与排错

– Pod创建失败，错误信息”exceeded quota”：检查命名空间资源配额使用情况，确认是否需要增加配额或释放闲置资源
– LimitRange导致Deployment无法创建：检查容器的resources设置是否超出LimitRange定义的max值
– 配额修改后旧Pod不受影响：ResourceQuota变更只影响新创建的Pod，已运行的Pod不会被驱逐
– GPU配额不生效：确保ResourceQuota中的GPU资源名称与节点上的device plugin注册名称一致

资源配额管理是多租户Kubernetes集群运维的基石。通过ResourceQuota控制总量、LimitRange约束边界、监控告警保障可见性、优先级机制保障关键服务，形成完整的资源管控体系。