Kubernetes 资源配额（ResourceQuota）深度解析-CSDN博客

本文链接：https://blog.csdn.net/gitblog_00114/article/details/148525191

Kubernetes 资源配额（ResourceQuota）深度解析

website Kubernetes website and documentation repo: 项目地址: https://gitcode.com/gh_mirrors/webs/website

什么是 Kubernetes 资源配额

在 Kubernetes 集群中，当多个团队或用户共享有限的集群资源时，资源配额（ResourceQuota）是管理员用来确保公平分配资源的关键机制。ResourceQuota 允许管理员为每个命名空间设置资源使用限制，防止单个团队或用户占用过多资源而影响其他用户。

资源配额的工作原理

资源配额通过 ResourceQuota 对象实现，主要功能包括：

资源限制：限制命名空间中可以使用的计算资源（CPU、内存）和存储资源总量
对象数量限制：限制命名空间中可以创建的特定类型对象（如 Pod、Service 等）的数量

当用户尝试在命名空间中创建资源时，Kubernetes 会检查是否超出配额限制。如果超出，请求会被拒绝并返回 403 Forbidden 错误。

配额类型详解

计算资源配额

计算资源配额限制命名空间中可以请求的计算资源总量：

| 资源名称 | 描述 | |---------|------| | limits.cpu | 所有 Pod 的 CPU 限额总和 | | limits.memory | 所有 Pod 的内存限额总和 | | requests.cpu | 所有 Pod 的 CPU 请求总和 | | requests.memory | 所有 Pod 的内存请求总和 | | hugepages-<size> | 指定大小的巨页请求总数 |

重要提示：对于 CPU 和内存资源，启用配额后，每个新 Pod 必须明确指定 requests 或 limits，否则创建会被拒绝。

存储资源配额

存储资源配额限制命名空间中的存储使用：

| 资源名称 | 描述 | |---------|------| | requests.storage | 所有 PVC 的存储请求总和 | | persistentvolumeclaims | 允许的 PVC 总数 | | <storage-class>.storageclass.storage.k8s.io/requests.storage | 特定存储类的存储请求总和 |

例如，可以为不同存储类设置不同配额：

gold.storageclass.storage.k8s.io/requests.storage: 500Gi
bronze.storageclass.storage.k8s.io/requests.storage: 100Gi

对象数量配额

限制命名空间中特定类型对象的数量：

核心组资源：count/<resource>（如 count/pods）
非核心组资源：count/<resource>.<group>（如 count/deployments.apps）

常见需要限制的对象包括：

count/persistentvolumeclaims
count/services
count/secrets
count/configmaps

配额范围（Scopes）

配额可以设置作用范围，仅对特定类型的资源生效：

Terminating：匹配 spec.activeDeadlineSeconds >= 0 的 Pod
NotTerminating：匹配 spec.activeDeadlineSeconds 为 nil 的 Pod
BestEffort：匹配服务质量为 BestEffort 的 Pod
NotBestEffort：匹配服务质量不为 BestEffort 的 Pod

最佳实践

结合 LimitRange 使用：为命名空间设置默认的资源请求和限制
合理规划配额：根据团队实际需求和集群容量设置配额
监控配额使用：定期检查配额使用情况，及时调整
考虑优先级：高优先级工作负载可能需要单独配额设置

配额配置示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"
    services: "10"
    persistentvolumeclaims: "20"
    requests.storage: 100Gi