×

由 `ResourceQuota` 对象定义的资源配额提供限制,以限制每个项目的聚合资源消耗。它可以限制按类型在项目中可以创建的对象数量,以及该项目中的资源可能消耗的计算资源和存储总量。

对象配额计数对所有标准命名空间资源类型设置定义的配额。使用资源配额时,如果对象存在于服务器存储中,则会针对配额收取该对象。这些类型的配额有助于防止存储资源耗尽。

本指南介绍了资源配额的工作原理以及开发人员如何使用和查看它们。

查看配额

您可以通过在 Web 控制台中导航到项目的“配额”页面来查看与项目配额中定义的任何硬性限制相关的使用统计信息。

您也可以使用 CLI 查看配额详细信息。

步骤
  1. 获取项目中定义的配额列表。例如,对于名为 `demoproject` 的项目

    $ oc get quota -n demoproject
    示例输出
    NAME                           AGE    REQUEST                                                                                                      LIMIT
    besteffort                     4s     pods: 1/2
    compute-resources-time-bound   10m    pods: 0/2                                                                                                    limits.cpu: 0/1, limits.memory: 0/1Gi
    core-object-counts             109s   configmaps: 2/10, persistentvolumeclaims: 1/4, replicationcontrollers: 1/20, secrets: 9/10, services: 2/10
  2. 描述您感兴趣的配额,例如 `core-object-counts` 配额

    $ oc describe quota core-object-counts -n demoproject
    示例输出
    Name:			core-object-counts
    Namespace:		demoproject
    Resource		Used	Hard
    --------		----	----
    configmaps		3	10
    persistentvolumeclaims	0	4
    replicationcontrollers	3	20
    secrets			9	10
    services		2	10

配额管理的资源

以下是配额可以管理的计算资源和对象类型的集合。

如果 `status.phase in (Failed, Succeeded)` 为真,则 Pod 处于终端状态。

表 1. 配额管理的计算资源
资源名称 描述

cpu

非终端状态下所有 Pod 的 CPU 请求总和不能超过此值。`cpu` 和 `requests.cpu` 值相同,可以互换使用。

memory

非终端状态下所有 Pod 的内存请求总和不能超过此值。memoryrequests.memory 值相同,可以互换使用。

requests.cpu

非终端状态下所有 Pod 的 CPU 请求总和不能超过此值。`cpu` 和 `requests.cpu` 值相同,可以互换使用。

requests.memory

非终端状态下所有 Pod 的内存请求总和不能超过此值。memoryrequests.memory 值相同,可以互换使用。

limits.cpu

非终端状态下所有 Pod 的 CPU 限制总和不能超过此值。

limits.memory

非终端状态下所有 Pod 的内存限制总和不能超过此值。

表 2. 配额管理的存储资源
资源名称 描述

requests.storage

所有持久卷声明的存储请求总和(无论状态如何)不能超过此值。

persistentvolumeclaims

项目中可以存在的持久卷声明总数。

<storage-class-name>.storageclass.storage.k8s.io/requests.storage

所有具有匹配存储类的持久卷声明的存储请求总和(无论状态如何)不能超过此值。

<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims

项目中可以存在的具有匹配存储类的持久卷声明总数。

ephemeral-storage

非终端状态下所有 Pod 的本地临时存储请求总和不能超过此值。ephemeral-storagerequests.ephemeral-storage 值相同,可以互换使用。

requests.ephemeral-storage

非终端状态下所有 Pod 的临时存储请求总和不能超过此值。ephemeral-storagerequests.ephemeral-storage 值相同,可以互换使用。

limits.ephemeral-storage

非终端状态下所有 Pod 的临时存储限制总和不能超过此值。

表 3. 配额管理的对象计数
资源名称 描述

pods

项目中可以存在的非终端状态 Pod 总数。

replicationcontrollers

项目中可以存在的副本控制器总数。

resourcequotas

项目中可以存在的资源配额总数。

services

项目中可以存在的服务总数。

services.loadbalancers

项目中可以存在的 LoadBalancer 类型服务总数。

services.nodeports

项目中可以存在的 NodePort 类型服务总数。

secrets

项目中可以存在的密钥总数。

configmaps

项目中可以存在的 ConfigMap 对象总数。

persistentvolumeclaims

项目中可以存在的持久卷声明总数。

openshift.io/imagestreams

项目中可以存在的镜像流总数。

配额范围

每个配额都可以有一组关联的范围。只有当配额与枚举范围的交集匹配时,它才会衡量资源的使用情况。

向配额添加范围会限制该配额可以应用到的资源集。指定允许集之外的资源会导致验证错误。

范围

描述

BestEffort

匹配 cpumemory 的服务质量为尽力而为的 Pod。

NotBestEffort

匹配 cpumemory 的服务质量不是尽力而为的 Pod。

BestEffort 范围将配额限制为限制以下资源

  • pods

NotBestEffort 范围将配额限制为跟踪以下资源

  • pods

  • memory

  • requests.memory

  • limits.memory

  • cpu

  • requests.cpu

  • limits.cpu

配额执行

项目资源配额首次创建后,项目会限制创建任何可能违反配额约束的新资源的能力,直到它计算出更新的使用情况统计数据。

配额创建并更新使用情况统计数据后,项目将接受新内容的创建。创建或修改资源时,您的配额使用量会在创建或修改资源的请求后立即递增。

删除资源时,您的配额使用量将在项目配额统计数据的下次完整重新计算期间递减。可配置的时间量决定了将配额使用情况统计数据减少到其当前观察到的系统值所需的时间。

如果项目修改超过配额使用限制,服务器将拒绝该操作,并向用户返回相应的错误消息,说明违反的配额约束以及他们当前在系统中观察到的使用情况统计数据。

请求与限制

分配计算资源时,每个容器都可能为 CPU、内存和临时存储分别指定请求值和限制值。配额可以限制这些值中的任何一个。

如果配额为 requests.cpurequests.memory 指定了值,则它要求每个传入容器都对这些资源发出明确的请求。如果配额为 limits.cpulimits.memory 指定了值,则它要求每个传入容器都为这些资源指定明确的限制。