计算资源配额 | 可扩展性和性能 | OpenShift Container Platform 4.17

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

使用配额和限制范围，集群管理员可以设置约束以限制项目中使用的对象数量或计算资源量。这有助于集群管理员更好地管理和分配所有项目中的资源，并确保没有项目使用超过集群大小的合适数量的资源。

配额由集群管理员设置，并作用于给定项目。OpenShift Container Platform 项目所有者可以更改其项目的配额，但不能更改限制范围。OpenShift Container Platform 用户无法修改配额或限制范围。

以下部分将帮助您了解如何检查配额和限制范围设置、它们可以约束哪些内容以及如何请求或限制您自己的 Pod 和容器中的计算资源。

由配额管理的资源

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

如果status.phase为Failed或Succeeded，则 Pod 处于终端状态。

表 1. 由配额管理的计算资源
资源名称	描述
`cpu`	非终端状态下所有 Pod 的 CPU 请求总和不能超过此值。`cpu`和`requests.cpu`值相同，可以互换使用。
`memory`	非终端状态下所有 Pod 的内存请求总和不能超过此值。`memory`和`requests.memory`值相同，可以互换使用。
`ephemeral-storage`	非终端状态下所有 Pod 的本地临时存储请求总和不能超过此值。`ephemeral-storage`和`requests.ephemeral-storage`值相同，可以互换使用。只有在启用临时存储技术预览版时，此资源才可用。此功能默认情况下处于禁用状态。
`requests.cpu`	非终端状态下所有 Pod 的 CPU 请求总和不能超过此值。`cpu`和`requests.cpu`值相同，可以互换使用。
`requests.memory`	非终端状态下所有 Pod 的内存请求总和不能超过此值。`memory`和`requests.memory`值相同，可以互换使用。
`requests.ephemeral-storage`	非终端状态下所有 Pod 的临时存储请求总和不能超过此值。`ephemeral-storage`和`requests.ephemeral-storage`值相同，可以互换使用。只有在启用临时存储技术预览版时，此资源才可用。此功能默认情况下处于禁用状态。
`limits.cpu`	非终端状态下所有 Pod 的 CPU 限制总和不能超过此值。
`limits.memory`	非终端状态下所有 Pod 的内存限制总和不能超过此值。
`limits.ephemeral-storage`	所有非终端状态 Pod 的瞬时存储限制总和不能超过此值。此资源仅在您启用瞬时存储技术预览版时可用。此功能默认情况下处于禁用状态。

表 2. 由配额管理的存储资源
资源名称	描述
`requests.storage`	所有持久卷声明的存储请求总和（无论其状态如何）不能超过此值。
`persistentvolumeclaims`	项目中可以存在的持久卷声明总数。
`<storage-class-name>.storageclass.storage.k8s.io/requests.storage`	所有具有匹配存储类的持久卷声明的存储请求总和（无论其状态如何）不能超过此值。
`<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims`	项目中可以存在的具有匹配存储类的持久卷声明总数。

表 3. 由配额管理的对象计数
资源名称	描述
`pods`	项目中可以存在的非终端状态 Pod 总数。
`replicationcontrollers`	项目中可以存在的副本控制器总数。
`resourcequotas`	项目中可以存在的资源配额总数。
`services`	项目中可以存在的服务总数。
`secrets`	项目中可以存在的密钥总数。
`configmaps`	项目中可以存在的`ConfigMap` 对象总数。
`persistentvolumeclaims`	项目中可以存在的持久卷声明总数。
`openshift.io/imagestreams`	项目中可以存在的镜像流总数。

您可以使用count/<resource>.<group>语法为这些标准命名空间资源类型配置对象计数配额。

$ oc create quota <name> --hard=count/<resource>.<group>=<quota> (1)

1	`<resource>`是资源的名称，`<group>`是 API 组（如果适用）。使用`kubectl api-resources`命令获取资源及其关联的 API 组列表。

为扩展资源设置资源配额

扩展资源不允许资源超额分配，因此您必须在配额中为相同的扩展资源指定requests和limits。目前，只有以requests.为前缀的配额项才允许用于扩展资源。以下是如何为 GPU 资源nvidia.com/gpu设置资源配额的示例场景。

步骤

要确定集群中节点上可用的 GPU 数量，请使用以下命令

$ oc describe node ip-172-31-27-209.us-west-2.compute.internal | egrep 'Capacity|Allocatable|gpu'

示例输出


                    openshift.com/gpu-accelerator=true
Capacity:
 nvidia.com/gpu:  2
Allocatable:
 nvidia.com/gpu:  2
 nvidia.com/gpu:  0           0

在此示例中，可用 2 个 GPU。

使用此命令在nvidia命名空间中设置配额。在此示例中，配额为1

$ cat gpu-quota.yaml

示例输出

apiVersion: v1
kind: ResourceQuota
metadata:
  name: gpu-quota
  namespace: nvidia
spec:
  hard:
    requests.nvidia.com/gpu: 1

使用以下命令创建配额

$ oc create -f gpu-quota.yaml

示例输出

resourcequota/gpu-quota created

使用以下命令验证命名空间是否设置了正确的配额

$ oc describe quota gpu-quota -n nvidia

示例输出

Name:                    gpu-quota
Namespace:               nvidia
Resource                 Used  Hard
--------                 ----  ----
requests.nvidia.com/gpu  0     1

使用以下命令运行请求单个 GPU 的 Pod

$ oc create pod gpu-pod.yaml

示例输出

apiVersion: v1
kind: Pod
metadata:
  generateName: gpu-pod-s46h7
  namespace: nvidia
spec:
  restartPolicy: OnFailure
  containers:
  - name: rhel7-gpu-pod
    image: rhel7
    env:
      - name: NVIDIA_VISIBLE_DEVICES
        value: all
      - name: NVIDIA_DRIVER_CAPABILITIES
        value: "compute,utility"
      - name: NVIDIA_REQUIRE_CUDA
        value: "cuda>=5.0"

    command: ["sleep"]
    args: ["infinity"]

    resources:
      limits:
        nvidia.com/gpu: 1

使用以下命令验证 Pod 是否正在运行

$ oc get pods

示例输出

NAME              READY     STATUS      RESTARTS   AGE
gpu-pod-s46h7     1/1       Running     0          1m

使用以下命令验证配额已使用计数器是否正确

$ oc describe quota gpu-quota -n nvidia

示例输出

Name:                    gpu-quota
Namespace:               nvidia
Resource                 Used  Hard
--------                 ----  ----
requests.nvidia.com/gpu  1     1

使用以下命令，尝试在nvidia命名空间中创建第二个 GPU Pod。从技术上讲，这在节点上可用，因为它有 2 个 GPU
```
$ oc create -f gpu-pod.yaml
```
示例输出
```
Error from server (Forbidden): error when creating "gpu-pod.yaml": pods "gpu-pod-f7z2w" is forbidden: exceeded quota: gpu-quota, requested: requests.nvidia.com/gpu=1, used: requests.nvidia.com/gpu=1, limited: requests.nvidia.com/gpu=1
```
出现此Forbidden错误消息是因为您的配额为 1 个 GPU，而此 Pod 尝试分配第二个 GPU，这超出了其配额。

配额范围

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

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

范围描述

范围	描述
`Terminating`	匹配`spec.activeDeadlineSeconds >= 0`的 Pod。
`NotTerminating`	匹配`spec.activeDeadlineSeconds`为`nil`的 Pod。
`BestEffort`	匹配`cpu`或`memory`具有最佳努力服务质量的 Pod。
`otBestEffort`	匹配`cpu`和`memory`不具有最佳努力服务质量的 Pod。

Terminating

匹配spec.activeDeadlineSeconds >= 0的 Pod。

NotTerminating

匹配spec.activeDeadlineSeconds为nil的 Pod。

BestEffort

匹配cpu或memory具有最佳努力服务质量的 Pod。

otBestEffort

匹配cpu和memory不具有最佳努力服务质量的 Pod。

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

pods

Terminating、NotTerminating和NotBestEffort范围将配额限制为跟踪以下资源

pods
memory
requests.memory
limits.memory
cpu
requests.cpu
limits.cpu
ephemeral-storage
requests.ephemeral-storage
limits.ephemeral-storage

仅当您启用瞬时存储技术预览版时，瞬时存储请求和限制才适用。此功能默认情况下处于禁用状态。

其他资源

有关计算资源的更多信息，请参阅由配额管理的资源。

有关提交计算资源的更多信息，请参阅服务质量类。

管理员配额使用情况

配额执行

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

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

删除资源时，您的配额使用情况将在项目的下一个完整配额统计信息重新计算期间递减。

可配置的时间量决定了将配额使用情况统计信息减少到其当前观察到的系统值所需的时间。

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

请求与限制的比较

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

如果配额为requests.cpu或requests.memory指定了值，则它要求每个传入容器都明确请求这些资源。如果配额为limits.cpu或limits.memory指定了值，则它要求每个传入容器都为这些资源指定明确的限制。

示例资源配额定义

示例 core-object-counts.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: core-object-counts
spec:
  hard:
    configmaps: "10" (1)
    persistentvolumeclaims: "4" (2)
    replicationcontrollers: "20" (3)
    secrets: "10" (4)
    services: "10" (5)

1	项目中可以存在的`ConfigMap` 对象总数。
2	项目中可以存在的持久卷声明 (PVC) 总数。
3	项目中可以存在的副本控制器总数。
4	项目中可以存在的密钥总数。
5	项目中可以存在的服务总数。

示例 openshift-object-counts.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: openshift-object-counts
spec:
  hard:
    openshift.io/imagestreams: "10" (1)

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

示例 compute-resources.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4" (1)
    requests.cpu: "1" (2)
    requests.memory: 1Gi (3)
    requests.ephemeral-storage: 2Gi (4)
    limits.cpu: "2" (5)
    limits.memory: 2Gi (6)
    limits.ephemeral-storage: 4Gi (7)

1	项目中可以存在的非终端状态 Pod 总数。
2	在所有非终端状态 Pod 中，CPU 请求总和不能超过 1 个核心。
3	在所有非终端状态 Pod 中，内存请求总和不能超过 1Gi。
4	在所有非终端状态 Pod 中，瞬时存储请求总和不能超过 2Gi。
5	在所有非终端状态 Pod 中，CPU 限制总和不能超过 2 个核心。
6	在所有非终端状态 Pod 中，内存限制总和不能超过 2Gi。
7	在所有非终端状态 Pod 中，瞬时存储限制总和不能超过 4Gi。

示例 besteffort.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort
spec:
  hard:
    pods: "1" (1)
  scopes:
  - BestEffort (2)

1	项目中可以存在处于非终端状态且服务质量为BestEffort的 Pod 的总数。
2	将配额限制为仅匹配内存或 CPU 服务质量为BestEffort的 Pod。

compute-resources-long-running.yaml 示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-long-running
spec:
  hard:
    pods: "4" (1)
    limits.cpu: "4" (2)
    limits.memory: "2Gi" (3)
    limits.ephemeral-storage: "4Gi" (4)
  scopes:
  - NotTerminating (5)

1	处于非终端状态的 Pod 总数。
2	所有处于非终端状态的 Pod 的 CPU 限制之和不能超过此值。
3	所有处于非终端状态的 Pod 的内存限制之和不能超过此值。
4	所有处于非终端状态的 Pod 的临时存储限制之和不能超过此值。
5	将配额限制为仅匹配`spec.activeDeadlineSeconds`设置为`nil`的 Pod。除非应用了`RestartNever`策略，否则构建 Pod 将属于`NotTerminating`。

compute-resources-time-bound.yaml 示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-time-bound
spec:
  hard:
    pods: "2" (1)
    limits.cpu: "1" (2)
    limits.memory: "1Gi" (3)
    limits.ephemeral-storage: "1Gi" (4)
  scopes:
  - Terminating (5)

1	处于非终端状态的 Pod 总数。
2	所有处于非终端状态的 Pod 的 CPU 限制之和不能超过此值。
3	所有处于非终端状态的 Pod 的内存限制之和不能超过此值。
4	所有处于非终端状态的 Pod 的临时存储限制之和不能超过此值。
5	将配额限制为仅匹配`spec.activeDeadlineSeconds >=0`的 Pod。例如，此配额将计费构建 Pod，但不计费长期运行的 Pod，例如 Web 服务器或数据库。

storage-consumption.yaml 示例

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-consumption
spec:
  hard:
    persistentvolumeclaims: "10" (1)
    requests.storage: "50Gi" (2)
    gold.storageclass.storage.k8s.io/requests.storage: "10Gi" (3)
    silver.storageclass.storage.k8s.io/requests.storage: "20Gi" (4)
    silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" (5)
    bronze.storageclass.storage.k8s.io/requests.storage: "0" (6)
    bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" (7)

1	项目中持久卷声明的总数
2	项目中所有持久卷声明的请求存储总和不能超过此值。
3	项目中所有持久卷声明中，在 gold 存储类中请求的存储总和不能超过此值。
4	项目中所有持久卷声明中，在 silver 存储类中请求的存储总和不能超过此值。
5	项目中所有持久卷声明中，silver 存储类的声明总数不能超过此值。
6	项目中所有持久卷声明中，在 bronze 存储类中请求的存储总和不能超过此值。当此值设置为`0`时，表示 bronze 存储类无法请求存储。
7	项目中所有持久卷声明中，在 bronze 存储类中请求的存储总和不能超过此值。当此值设置为`0`时，表示 bronze 存储类无法创建声明。

创建配额

要创建配额，首先在一个文件中定义配额。然后使用该文件将其应用于项目。有关此说明的链接，请参见“其他资源”部分。

$ oc create -f <resource_quota_definition> [-n <project_name>]

这是一个使用core-object-counts.yaml资源配额定义和demoproject项目名称的示例。

$ oc create -f core-object-counts.yaml -n demoproject

创建对象计数配额

您可以为所有 OpenShift Container Platform 标准命名空间资源类型（例如BuildConfig和DeploymentConfig）创建对象计数配额。对象配额计数对所有标准命名空间资源类型设置定义的配额。

使用资源配额时，如果对象存在于服务器存储中，则会针对配额对对象进行计费。这些类型的配额对于防止存储资源耗尽非常有用。

要为资源配置对象计数配额，请运行以下命令。

$ oc create quota <name> --hard=count/<resource>.<group>=<quota>,count/<resource>.<group>=<quota>

显示对象计数配额的示例

$ oc create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4
resourcequota "test" created

$ oc describe quota test
Name:                         test
Namespace:                    quota
Resource                      Used  Hard
--------                      ----  ----
count/deployments.extensions  0     2
count/pods                    0     3
count/replicasets.extensions  0     4
count/secrets                 0     4

此示例将集群中每个项目中列出的资源限制为每个资源的硬限制。

查看配额

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

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

首先，获取项目中定义的配额列表。例如，对于名为demoproject的项目。

$ oc get quota -n demoproject
NAME                AGE
besteffort          11m
compute-resources   2m
core-object-counts  29m

描述您感兴趣的配额，例如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

配置配额同步周期

删除一组资源后，资源的同步时间范围由/etc/origin/master/master-config.yaml文件中resource-quota-sync-period设置确定。

在配额使用恢复之前，用户在尝试重用资源时可能会遇到问题。您可以更改resource-quota-sync-period设置，使资源集在所需的时间内（以秒为单位）重新生成，以便资源再次可用。

resource-quota-sync-period设置示例

kubernetesMasterConfig:
  apiLevels:
  - v1beta3
  - v1
  apiServerArguments: null
  controllerArguments:
    resource-quota-sync-period:
      - "10s"

进行任何更改后，重新启动控制器服务以应用这些更改。

$ master-restart api
$ master-restart controllers

调整重新生成时间对于创建资源和确定使用自动化时的资源使用情况很有帮助。

resource-quota-sync-period设置平衡系统性能。缩短同步周期可能会导致控制器负载过重。

显式配额以使用资源

如果资源不受配额管理，则用户对可以使用的资源量没有限制。例如，如果没有与 gold 存储类相关的存储配额，则项目可以创建的 gold 存储量是无限的。

对于高成本的计算或存储资源，管理员可以要求授予显式配额以使用资源。例如，如果项目没有显式地获得与 gold 存储类相关的存储配额，则该项目的用户将无法创建任何此类存储。

为了要求显式配额才能使用特定资源，应将以下节添加到 master-config.yaml 中。

admissionConfig:
  pluginConfig:
    ResourceQuota:
      configuration:
        apiVersion: resourcequota.admission.k8s.io/v1alpha1
        kind: Configuration
        limitedResources:
        - resource: persistentvolumeclaims (1)
        matchContains:
        - gold.storageclass.storage.k8s.io/requests.storage (2)

1	默认情况下，其使用受限的组或资源。
2	与默认限制的组/资源关联的、由配额跟踪的资源的名称。

在上面的示例中，配额系统拦截创建或更新PersistentVolumeClaim的每个操作。它检查将消耗哪些受配额控制的资源。如果项目中没有覆盖这些资源的配额，则请求将被拒绝。在此示例中，如果用户创建使用与 gold 存储类关联的存储的PersistentVolumeClaim，并且项目中没有匹配的配额，则请求将被拒绝。

其他资源

有关如何创建设置配额所需文件的示例，请参见受配额管理的资源。

关于如何分配受配额管理的计算资源的说明。

有关管理项目资源的限制和配额的信息，请参见使用项目。

如果已为您的项目定义了配额，请参见了解部署，了解集群配置中的注意事项。

设置限制范围

由LimitRange对象定义的限制范围在 Pod、容器、镜像、镜像流和持久卷声明级别定义计算资源约束。限制范围指定 Pod、容器、镜像、镜像流或持久卷声明可以使用的资源量。

所有创建和修改资源的请求都将针对项目中的每个LimitRange对象进行评估。如果资源违反任何列出的约束，则该资源将被拒绝。如果资源未设置显式值，并且如果约束支持默认值，则默认值将应用于该资源。

对于 CPU 和内存限制，如果指定最大值但不指定最小限制，则资源可以消耗超过最大值的 CPU 和内存资源。

核心限制范围对象定义

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "core-resource-limits" (1)
spec:
  limits:
    - type: "Pod"
      max:
        cpu: "2" (2)
        memory: "1Gi" (3)
      min:
        cpu: "200m" (4)
        memory: "6Mi" (5)
    - type: "Container"
      max:
        cpu: "2" (6)
        memory: "1Gi" (7)
      min:
        cpu: "100m" (8)
        memory: "4Mi" (9)
      default:
        cpu: "300m" (10)
        memory: "200Mi" (11)
      defaultRequest:
        cpu: "200m" (12)
        memory: "100Mi" (13)
      maxLimitRequestRatio:
        cpu: "10" (14)

1	限制范围对象的名称。
2	Pod 在节点上所有容器中可以请求的最大 CPU 量。
3	Pod 在节点上所有容器可请求的最大内存量。
4	Pod 在节点上所有容器可请求的最小 CPU 量。如果不设置`min`值或将`min`设置为`0`，则表示没有限制，Pod 可以消耗超过`max` CPU 值的资源。
5	Pod 在节点上所有容器可请求的最小内存量。如果不设置`min`值或将`min`设置为`0`，则表示没有限制，Pod 可以消耗超过`max`内存值的资源。
6	Pod 中单个容器可请求的最大 CPU 量。
7	Pod 中单个容器可请求的最大内存量。
8	Pod 中单个容器可请求的最小 CPU 量。如果不设置`min`值或将`min`设置为`0`，则表示没有限制，Pod 可以消耗超过`max` CPU 值的资源。
9	Pod 中单个容器可请求的最小内存量。如果不设置`min`值或将`min`设置为`0`，则表示没有限制，Pod 可以消耗超过`max`内存值的资源。
10	如果在 Pod 规范中未指定限制，则容器的默认 CPU 限制。
11	如果在 Pod 规范中未指定限制，则容器的默认内存限制。
12	如果在 Pod 规范中未指定请求，则容器的默认 CPU 请求。
13	如果在 Pod 规范中未指定请求，则容器的默认内存请求。
14	容器的最大限制与请求比率。

OpenShift Container Platform 限制范围对象定义

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "openshift-resource-limits"
spec:
  limits:
    - type: openshift.io/Image
      max:
        storage: 1Gi (1)
    - type: openshift.io/ImageStream
      max:
        openshift.io/image-tags: 20 (2)
        openshift.io/images: 30 (3)
    - type: "Pod"
      max:
        cpu: "2" (4)
        memory: "1Gi" (5)
        ephemeral-storage: "1Gi" (6)
      min:
        cpu: "1" (7)
        memory: "1Gi" (8)

1	可以推送到内部注册表的镜像的最大大小。
2	镜像流规范中定义的唯一镜像标签的最大数量。
3	镜像流状态规范中定义的唯一镜像引用的最大数量。
4	Pod 在节点上所有容器中可以请求的最大 CPU 量。
5	Pod 在节点上所有容器可请求的最大内存量。
6	Pod 在节点上所有容器可请求的瞬时存储的最大量。
7	Pod 在节点上所有容器可请求的最小 CPU 量。请参阅“支持的约束”表以获取重要信息。
8	Pod 在节点上所有容器可请求的最小内存量。如果不设置`min`值或将`min`设置为`0`，则表示没有限制，Pod 可以消耗超过`max`内存值的资源。

您可以在一个限制范围对象中同时指定核心和 OpenShift Container Platform 资源。

容器限制

支持的资源

CPU
内存

支持的约束

每个容器，如果已指定，则必须满足以下条件

容器

约束行为

约束	行为
`最小值(Min)`	`Min[<resource>]` 小于或等于 `container.resources.requests[<resource>]`（必需）小于或等于 `container/resources.limits[<resource>]`（可选）如果配置定义了`min` CPU，则请求值必须大于 CPU 值。如果不设置`min`值或将`min`设置为`0`，则表示没有限制，Pod 可以消耗超过`max`值的资源。
`最大值(Max)`	`container.resources.limits[<resource>]`（必需）小于或等于`Max[<resource>]` 如果配置定义了`max` CPU，则不需要定义 CPU 请求值。但是，必须设置一个满足限制范围中指定的最大 CPU 约束的限制。
`最大限制请求比率(MaxLimitRequestRatio)`	`MaxLimitRequestRatio[<resource>]` 小于或等于 (`container.resources.limits[<resource>]` / `container.resources.requests[<resource>]`) 如果限制范围定义了`maxLimitRequestRatio`约束，则任何新容器都必须同时具有`request`和`limit`值。此外，OpenShift Container Platform 通过将`limit`除以`request`来计算限制与请求的比率。结果应为大于 1 的整数。例如，如果容器的`limit`值为`cpu: 500`，`request`值为`cpu: 100`，则`cpu`的限制与请求比率为`5`。此比率必须小于或等于`maxLimitRequestRatio`。

最小值(Min)

Min[<resource>] 小于或等于 container.resources.requests[<resource>]（必需）小于或等于 container/resources.limits[<resource>]（可选）

如果配置定义了min CPU，则请求值必须大于 CPU 值。如果不设置min值或将min设置为0，则表示没有限制，Pod 可以消耗超过max值的资源。

最大值(Max)

container.resources.limits[<resource>]（必需）小于或等于Max[<resource>]

如果配置定义了max CPU，则不需要定义 CPU 请求值。但是，必须设置一个满足限制范围中指定的最大 CPU 约束的限制。

最大限制请求比率(MaxLimitRequestRatio)

MaxLimitRequestRatio[<resource>] 小于或等于 (container.resources.limits[<resource>] / container.resources.requests[<resource>])

如果限制范围定义了maxLimitRequestRatio约束，则任何新容器都必须同时具有request和limit值。此外，OpenShift Container Platform 通过将limit除以request来计算限制与请求的比率。结果应为大于 1 的整数。

例如，如果容器的limit值为cpu: 500，request值为cpu: 100，则cpu的限制与请求比率为5。此比率必须小于或等于maxLimitRequestRatio。

支持的默认值

Default[<resource>]: 如果未指定，则将container.resources.limit[<resource>]默认为指定值。
Default Requests[<resource>]: 如果未指定，则将container.resources.requests[<resource>]默认为指定值。

Pod 限制

支持的资源

CPU
内存

支持的约束

对于 Pod 中的所有容器，必须满足以下条件

表 4. Pod
约束	强制执行的行为
`最小值(Min)`	`Min[<resource>]` 小于或等于 `container.resources.requests[<resource>]`（必需）小于或等于 `container.resources.limits[<resource>]`。如果不设置`min`值或将`min`设置为`0`，则表示没有限制，Pod 可以消耗超过`max`值的资源。
`最大值(Max)`	`container.resources.limits[<resource>]`（必需）小于或等于`Max[<resource>]`。
`最大限制请求比率(MaxLimitRequestRatio)`	`MaxLimitRequestRatio[<resource>]` 小于或等于 (`container.resources.limits[<resource>]` / `container.resources.requests[<resource>]`)。

镜像限制

支持的资源

存储

资源类型名称

openshift.io/Image

每个镜像，如果已指定，则必须满足以下条件

表 5. 镜像
约束	行为
`最大值(Max)`	`image.dockerimagemetadata.size` 小于或等于 `Max[<resource>]`

为了防止大小超过限制的 Blob 上传到注册表，必须配置注册表以强制执行配额。REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA环境变量必须设置为true。默认情况下，对于新的部署，此环境变量设置为true。

镜像流限制

支持的资源

openshift.io/image-tags
openshift.io/images

资源类型名称

openshift.io/ImageStream

每个镜像流，如果已指定，则必须满足以下条件

表 6. ImageStream
约束	行为
`Max[openshift.io/image-tags]`	`length( uniqueimagetags( imagestream.spec.tags ) )` 小于或等于 `Max[openshift.io/image-tags]` `uniqueimagetags` 返回给定规范标签的镜像的唯一引用。
`Max[openshift.io/images]`	`length( uniqueimages( imagestream.status.tags ) )` 小于或等于 `Max[openshift.io/images]` `uniqueimages` 返回在状态标签中找到的唯一镜像名称。名称等于镜像的摘要。

镜像引用的计数

openshift.io/image-tags 资源表示唯一的流限制。可能的引用是ImageStreamTag、ImageStreamImage或DockerImage。可以使用oc tag和oc import-image命令或使用镜像流来创建标签。内部和外部引用之间没有区别。但是，在镜像流规范中标记的每个唯一引用只计算一次。它不会以任何方式限制推送到内部容器镜像注册表，但对于标签限制很有用。

openshift.io/images 资源表示记录在镜像流状态中的唯一镜像名称。它有助于限制可以推送到内部注册表的多个镜像。内部和外部引用没有区别。

PersistentVolumeClaim 限制

支持的资源

存储

支持的约束

对于项目中的所有持久卷声明，必须满足以下条件

表 7. Pod
约束	强制执行的行为
`最小值(Min)`	Min[<resource>] <= claim.spec.resources.requests[<resource>]（必需）
`最大值(Max)`	claim.spec.resources.requests[<resource>]（必需）<= Max[<resource>]

限制范围对象定义

{
  "apiVersion": "v1",
  "kind": "LimitRange",
  "metadata": {
    "name": "pvcs" (1)
  },
  "spec": {
    "limits": [{
        "type": "PersistentVolumeClaim",
        "min": {
          "storage": "2Gi" (2)
        },
        "max": {
          "storage": "50Gi" (3)
        }
      }
    ]
  }
}

1	限制范围对象的名称。
2	可以在持久卷声明中请求的最小存储量。
3	可以在持久卷声明中请求的最大存储量。

其他资源

有关流限制的信息，请参阅管理镜像流。

有关流限制的信息，请参见此处。

有关计算资源约束的更多信息，请参见此处。

有关如何测量 CPU 和内存的更多信息，请参见推荐的控制平面实践。

您可以指定短暂存储的限制和请求。有关此功能的更多信息，请参见理解短暂存储。

限制范围操作

创建限制范围

此处显示了创建限制范围的示例过程。

步骤

创建对象

$ oc create -f <limit_range_file> -n <project>

查看限制

您可以通过在 Web 控制台中导航到项目的配额页面来查看项目中定义的任何限制范围。您也可以使用 CLI 通过执行以下步骤来查看限制范围详细信息

步骤

获取项目中定义的限制范围对象的列表。例如，名为demoproject的项目
```
$ oc get limits -n demoproject
```
示例输出
```
NAME              AGE
resource-limits   6d
```

描述限制范围。例如，对于名为resource-limits的限制范围

$ oc describe limits resource-limits -n demoproject

示例输出

Name:                           resource-limits
Namespace:                      demoproject
Type                            Resource                Min     Max     Default Request Default Limit   Max Limit/Request Ratio
----                            --------                ---     ---     --------------- -------------   -----------------------
Pod                             cpu                     200m    2       -               -               -
Pod                             memory                  6Mi     1Gi     -               -               -
Container                       cpu                     100m    2       200m            300m            10
Container                       memory                  4Mi     1Gi     100Mi           200Mi           -
openshift.io/Image              storage                 -       1Gi     -               -               -
openshift.io/ImageStream        openshift.io/image      -       12      -               -               -
openshift.io/ImageStream        openshift.io/image-tags -       10      -               -               -

删除限制范围

要删除限制范围，请运行以下命令

$ oc delete limits <limit_name>

其他资源

有关在用户可以创建的项目数量上强制执行不同限制、管理限制以及项目资源配额的信息，请参见每个项目的资源配额。