title: “K8s 系列 | 第 21 天：资源配额与 LimitRange：多租户资源管控”
tags:
– Kubernetes
– K8s系列
– DevOps
– 资源配额
– 多租户
– ResourceQuota
– LimitRange
– 云原生

K8s 系列 | 第 21 天：资源配额与 LimitRange：多租户资源管控

第 21/30 天

一、引言

在真实的 Kubernetes 生产环境中，多个团队、多个应用常常共享同一个集群。如果没有资源管控机制，一个”喧闹邻居”（Noisy Neighbor）应用可能耗尽集群资源，导致其他关键服务不可用。Kubernetes 提供了 ResourceQuota 和 LimitRange 两个核心资源管控机制，实现多租户隔离与资源公平分配。

本文深入讲解 ResourceQuota 和 LimitRange 的原理、配置实战以及生产环境最佳实践，帮助你构建健壮的多租户 K8s 集群。

二、核心概念

2.1 ResourceQuota（资源配额）

ResourceQuota 是一个命名空间级别的资源限制策略，用于约束该命名空间内所有 Pod 的资源总和上限。它限制两类资源：

计算资源：CPU、内存的 requests 和 limits 总和上限
存储资源：PVC 的存储请求总和上限
对象数量：Pod、Service、ConfigMap、PVC 等 K8s 对象的最大数量

2.2 LimitRange（限制范围）

LimitRange 同样是命名空间级别的策略，但作用在单个 Pod 或容器级别。它解决以下问题：

为未显式设置资源 requests/limits 的 Pod 设置默认值
约束单个 Pod/容器能使用的最大/最小资源量
约束 PVC 的存储请求范围

2.3 两者的关系

维度	ResourceQuota	LimitRange
作用范围	命名空间内所有资源总和	单个 Pod / 容器 / PVC
主要目的	防止资源耗尽	防止单个 Pod 过度占用
默认值设置	❌ 不支持	✅ 支持默认 requests/limits

两者配合使用效果最佳。ResourceQuota 设定总量上限，LimitRange 确保每个 Pod 的资源配置合理。

三、实战步骤

3.1 创建测试命名空间

kubectl create namespace quota-demo

3.2 配置 ResourceQuota

创建 resource-quota.yaml：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: quota-demo
spec:
  hard:
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"
    persistentvolumeclaims: "10"
    pods: "20"
    services: "10"
    configmaps: "10"
    secrets: "20"

应用配额并查看状态：

kubectl apply -f resource-quota.yaml

# 查看配额详情
kubectl get resourcequota team-quota -n quota-demo -o yaml

# 查看配额使用情况
kubectl describe quota team-quota -n quota-demo

输出示例：

Name:         team-quota
Namespace:    quota-demo
Resource      Used  Hard
--------      ---   ---
configmaps    0     10
limits.cpu    0     8
limits.memory 0     16Gi
pods          0     20
persistentvolumeclaims 0 10
requests.cpu  0     4
requests.memory 0   8Gi
secrets       0     20
services      0     10

3.3 配置 LimitRange

创建 limit-range.yaml：

apiVersion: v1
kind: LimitRange
metadata:
  name: team-limits
  namespace: quota-demo
spec:
  limits:
    - default:
        cpu: "500m"
        memory: "512Mi"
      defaultRequest:
        cpu: "200m"
        memory: "256Mi"
      max:
        cpu: "2"
        memory: "4Gi"
      min:
        cpu: "50m"
        memory: "64Mi"
      type: Container

default：容器未设置 limits 时的默认值
defaultRequest：容器未设置 requests 时的默认值
max：单个容器允许的最大资源限制
min：单个容器允许的最小资源请求

kubectl apply -f limit-range.yaml
kubectl describe limitrange team-limits -n quota-demo

3.4 验证资源管控效果

部署一个测试 Pod 验证配额限制：

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: quota-demo
spec:
  containers:
    - name: nginx
      image: nginx:latest
      resources:
        requests:
          cpu: "1"
          memory: "1Gi"
        limits:
          cpu: "2"
          memory: "2Gi"

尝试创建一个超出配额限制的 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: oversized-pod
  namespace: quota-demo
spec:
  containers:
    - name: nginx
      image: nginx:latest
      resources:
        requests:
          cpu: "8"    # 超出团队配额 (4 CPU requests)
          memory: "10Gi"  # 超出团队配额 (8Gi memory requests)

kubectl apply -f oversized-pod.yaml
# 预期输出：Error from server (Forbidden): ... exceeds quota

3.5 存储配额实战

限制命名空间内的存储使用：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-quota
  namespace: quota-demo
spec:
  hard:
    requests.storage: "100Gi"
    persistentvolumeclaims: "10"
    ssd.storageclass.storage.k8s.io/requests.storage: "50Gi"
    standard.storageclass.storage.k8s.io/requests.storage: "50Gi"

这限制了不同 StorageClass 的存储用量上限，确保某一类存储不会被单个团队消耗殆尽。

四、常见问题与最佳实践

4.1 常见问题

Q1：ResourceQuota 和 LimitRange 必须同时配置吗？

不是必须，但强烈建议配合使用。只配置 ResourceQuota 而不配 LimitRange 时，未设置资源 requests 的 Pod 可能导致配额计算混乱。LimitRange 提供了默认值兜底，确保每个 Pod 都有明确的资源声明。

Q2：为命名空间设置 ResourceQuota 后，为什么 Pod 创建失败？

最常见的原因是 Pod 没有设置资源 requests/limits，而 LimitRange 也未配置默认值。Kubernetes 要求配额生效时，所有 Pod 都必须有显式的资源声明。

Q3：如何为不同团队设置不同的资源配额？

为每个团队创建独立的 Namespace，然后为每个 Namespace 应用不同的 ResourceQuota 和 LimitRange。这是最常用的多租户隔离模式。

Q4：配额可以动态调整吗？

可以。直接修改 ResourceQuota 对象的 spec.hard 字段即可，修改会立即生效。但需要注意，如果新配额低于当前使用量，已运行的 Pod 不会被驱逐，但新的 Pod 创建将被拒绝，直到资源释放。

4.2 生产最佳实践

配额分层设计：根据不同团队/业务的重要性设置不同配额 — 核心业务分配更多资源，开发/测试环境分配较少资源
监控告警联动：结合 Prometheus 监控配额使用率，当使用量达到 80% 时发出告警，避免业务突增时被拒绝
LimitRange 兜底策略：始终为每个命名空间配置 LimitRange 的默认值，防止未设置资源限制的 Pod 逃逸管控
范围限定配额：使用 scopes 字段可以针对特定状态的 Pod 设置配额，如 Terminating 和 NotTerminating
定期审计：通过 kubectl describe quota 定期检查各命名空间的资源使用情况，及时调整配额分配

4.3 多租户资源隔离架构

┌─────────────────────────────────────────────────────┐
│                    K8s 集群                           │
│                                                      │
│  ┌───────────┐  ┌───────────┐  ┌───────────┐        │
│  │ Team A    │  │ Team B    │  │ Team C    │        │
│  │ Namespace │  │ Namespace │  │ Namespace │        │
│  │           │  │           │  │           │        │
│  │ Quota:    │  │ Quota:    │  │ Quota:    │        │
│  │ 4 CPU     │  │ 8 CPU     │  │ 2 CPU     │        │
│  │ 8Gi Mem   │  │ 16Gi Mem  │  │ 4Gi Mem   │        │
│  │ 20 Pods   │  │ 40 Pods   │  │ 10 Pods   │        │
│  └───────────┘  └───────────┘  └───────────┘        │
│                                                      │
│  ┌──────────────────────────────────────────────┐    │
│  │  Cluster Autoscaler: 集群资源不足时自动扩容     │    │
│  └──────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────┘