Setting Limit Ranges

Overview

A limit range, defined by a **LimitRange** object, enumerates compute resource constraints in a project at the pod, container, image, image stream, and persistent volume claim level, and specifies the amount of resources that a pod, container, image, image stream, or persistent volume claim can consume.

All resource create and modification requests are evaluated against each **LimitRange** object in the project. If the resource violates any of the enumerated constraints, then the resource is rejected. If the resource does not set an explicit value, and if the constraint supports a default value, then the default value is applied to the resource.

For CPU and Memory limits, if you specify a max value, but do not specify a min limit, the resource can consume CPU/memory resources greater than max value`.

You can specify limits and requests for ephemeral storage by using the ephemeral storage technology preview. This feature is disabled by default. To enable this feature, see configuring for ephemeral storage.

Core Limit Range Object Definition

  1. apiVersion: "v1"
  2. kind: "LimitRange"
  3. metadata:
  4. name: "core-resource-limits" (1)
  5. spec:
  6. limits:
  7. - type: "Pod"
  8. max:
  9. cpu: "2" (2)
  10. memory: "1Gi" (3)
  11. min:
  12. cpu: "200m" (4)
  13. memory: "6Mi" (5)
  14. - type: "Container"
  15. max:
  16. cpu: "2" (6)
  17. memory: "1Gi" (7)
  18. min:
  19. cpu: "100m" (8)
  20. memory: "4Mi" (9)
  21. default:
  22. cpu: "300m" (10)
  23. memory: "200Mi" (11)
  24. defaultRequest:
  25. cpu: "200m" (12)
  26. memory: "100Mi" (13)
  27. maxLimitRequestRatio:
  28. cpu: "10" (14)
1The name of the limit range object.
2The maximum amount of CPU that a pod can request on a node across all containers.
3The maximum amount of memory that a pod can request on a node across all containers.
4The minimum amount of CPU that a pod can request on a node across all containers. Not setting a min value or setting 0 is unlimited allowing the pod to consume more than the max value.
5The minimum amount of memory that a pod can request on a node across all containers. Not setting a min value or setting 0 is unlimited allowing the pod to consume more than the max value.
6The maximum amount of CPU that a single container in a pod can request.
7The maximum amount of memory that a single container in a pod can request.
8The minimum amount of CPU that a single container in a pod can request. Not setting a min value or setting 0 is unlimited allowing the pod to consume more than the max value.
9The minimum amount of memory that a single container in a pod can request. Not setting a min value or setting 0 is unlimited allowing the pod to consume more than the max value.
10The default amount of CPU that a container will be limited to use if not specified.
11The default amount of memory that a container will be limited to use if not specified.
12The default amount of CPU that a container will request to use if not specified.
13The default amount of memory that a container will request to use if not specified.
14The maximum amount of CPU burst that a container can make as a ratio of its limit over request.

For more information on how CPU and memory are measured, see Compute Resources.

OKD Limit Range Object Definition

  1. apiVersion: "v1"
  2. kind: "LimitRange"
  3. metadata:
  4. name: "openshift-resource-limits"
  5. spec:
  6. limits:
  7. - type: openshift.io/Image
  8. max:
  9. storage: 1Gi (1)
  10. - type: openshift.io/ImageStream
  11. max:
  12. openshift.io/image-tags: 20 (2)
  13. openshift.io/images: 30 (3)
  14. - type: "Pod"
  15. max:
  16. cpu: "2" (4)
  17. memory: "1Gi" (5)
  18. ephemeral-storage: "1Gi" (6)
  19. max:
  20. cpu: "1" (7)
  21. memory: "1Gi" (8)
1The maximum size of an image that can be pushed to an internal registry.
2The maximum number of unique image tags per image stream’s spec.
3The maximum number of unique image references per image stream’s status.
4The maximum amount of CPU that a pod can request on a node across all containers.
5The maximum amount of memory that a pod can request on a node across all containers.
6The maximum amount of ephemeral storage that a pod can request on a node across all containers, if the ephemeral storage technology preview is enabled.
7The minimum amount of CPU that a pod can request on a node across all containers. Not setting a min value or setting 0 is unlimited allowing the pod to consume more than the max value.
8The minimum amount of memory that a pod can request on a node across all containers. Not setting a min value or setting 0 is unlimited allowing the pod to consume more than the max value.

Both core and OKD resources can be specified in just one limit range object. They are separated here into two examples for clarity.

Container Limits

Supported Resources:

  • CPU

  • Memory

Supported Constraints:

Per container, the following must hold true if specified:

Table 1. Container
ConstraintBehavior

Min

Min[resource] less than or equal to container.resources.requests[resource] (required) less than or equal to container/resources.limits[resource] (optional)

If the configuration defines a min CPU, then the request value must be greater than the CPU value. Not setting a min value or setting 0 is unlimited allowing the pod to consume more than the max value.

Max

container.resources.limits[resource] (required) less than or equal to Max[resource]

If the configuration defines a max CPU, then you do not need to define a request value, but a limit value does need to be set that satisfies the maximum CPU constraint.

MaxLimitRequestRatio

MaxLimitRequestRatio[resource] less than or equal to ( container.resources.limits[resource] / container.resources.requests[resource])

If a configuration defines a maxLimitRequestRatio value, then any new containers must have both a request and limit value. Additionally, OKD calculates a limit to request ratio by dividing the limit by the request. This value should be a non-negative integer greater than 1.

For example, if a container has cpu: 500 in the limit value, and cpu: 100 in the request value, then its limit to request ratio for cpu is 5. This ratio must be less than or equal to the maxLimitRequestRatio.

Supported Defaults:

Default[resource]

Defaults container.resources.limit[resource] to specified value if none.

Default Requests[resource]

Defaults container.resources.requests[resource] to specified value if none.

Pod Limits

Supported Resources:

  • CPU

  • Memory

Supported Constraints:

Across all containers in a pod, the following must hold true:

Table 2. Pod
ConstraintEnforced Behavior

Min

Min[resource] less than or equal to container.resources.requests[resource] (required) less than or equal to container.resources.limits[resource]. Not setting a min value or setting 0 is unlimited allowing the pod to consume more than the max value.

Max

container.resources.limits[resource] (required) less than or equal to Max[resource].

MaxLimitRequestRatio

MaxLimitRequestRatio[resource] less than or equal to ( container.resources.limits[resource] / container.resources.requests[resource]).

Image Limits

Supported Resources:

  • Storage

Resource type name:

  • openshift.io/Image

Per image, the following must hold true if specified:

Table 3. Image
ConstraintBehavior

Max

image.dockerimagemetadata.size less than or equal to Max[resource]

To prevent blobs exceeding the limit from being uploaded to the registry, the registry must be configured to enforce quota. An environment variable REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA must be set to true which is done by default for new deployments.

The image size is not always available in the manifest of an uploaded image. This is especially the case for images built with Docker 1.10 or higher and pushed to a v2 registry. If such an image is pulled with an older Docker daemon, the image manifest will be converted by the registry to schema v1 lacking all the size information. No storage limit set on images will prevent it from being uploaded.

The issue is being addressed.

Image Stream Limits

Supported Resources:

  • openshift.io/image-tags

  • openshift.io/images

Resource type name:

  • openshift.io/ImageStream

Per image stream, the following must hold true if specified:

Table 4. ImageStream
ConstraintBehavior

Max[openshift.io/image-tags]

length( uniqueimagetags( imagestream.spec.tags ) ) less than or equal to Max[openshift.io/image-tags]

uniqueimagetags returns unique references to images of given spec tags.

Max[openshift.io/images]

length( uniqueimages( imagestream.status.tags ) ) less than or equal to Max[openshift.io/images]

uniqueimages returns unique image names found in status tags. The name equals image’s digest.

Counting of Image References

Resource openshift.io/image-tags represents unique image references. Possible references are an **ImageStreamTag**, an **ImageStreamImage** and a **DockerImage**. They may be created using commands oc tag and oc import-image or by using tag tracking. No distinction is made between internal and external references. However, each unique reference tagged in the image stream’s specification is counted just once. It does not restrict pushes to an internal container image registry in any way, but is useful for tag restriction.

Resource openshift.io/images represents unique image names recorded in image stream status. It allows for restriction of a number of images that can be pushed to the internal registry. Internal and external references are not distinguished.

PersistentVolumeClaim Limits

Supported Resources:

  • Storage

Supported Constraints:

Across all persistent volume claims in a project, the following must hold true:

Table 5. Pod
ConstraintEnforced Behavior

Min

Min[resource] ⇐ claim.spec.resources.requests[resource] (required)

Max

claim.spec.resources.requests[resource] (required) ⇐ Max[resource]

Limit Range Object Definition

  1. {
  2. "apiVersion": "v1",
  3. "kind": "LimitRange",
  4. "metadata": {
  5. "name": "pvcs" (1)
  6. },
  7. "spec": {
  8. "limits": [{
  9. "type": "PersistentVolumeClaim",
  10. "min": {
  11. "storage": "2Gi" (2)
  12. },
  13. "max": {
  14. "storage": "50Gi" (3)
  15. }
  16. }
  17. ]
  18. }
  19. }
1The name of the limit range object.
2The minimum amount of storage that can be requested in a persistent volume claim
3The maximum amount of storage that can be requested in a persistent volume claim

Creating a Limit Range

To apply a limit range to a project, create a limit range object definition on your file system to your desired specifications, then run:

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

Viewing Limits

You can view any limit ranges defined in a project by navigating in the web console to the project’s Quota page.

You can also use the CLI to view limit range details:

  1. First, get the list of limit ranges defined in the project. For example, for a project called demoproject:

    1. $ oc get limits -n demoproject
    2. NAME AGE
    3. resource-limits 6d
  2. Then, describe the limit range you are interested in, for example the resource-limits limit range:

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

Deleting Limits

Remove any active limit range to no longer enforce the limits of a project:

  1. $ oc delete limits <limit_name>