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.
Example 1. Core Limit Range Object Definition
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 |
The name of the limit range object. |
2 |
The maximum amount of CPU that a pod can request on a node across all
containers. |
3 |
The maximum amount of memory that a pod can request on a node across all
containers. |
4 |
The minimum amount of CPU that a pod can request on a node across all
containers. |
5 |
The minimum amount of memory that a pod can request on a node across all
containers. |
6 |
The maximum amount of CPU that a single container in a pod can request. |
7 |
The maximum amount of memory that a single container in a pod can request. |
8 |
The minimum amount of CPU that a single container in a pod can request. |
9 |
The minimum amount of memory that a single container in a pod can request. |
10 |
The default amount of CPU that a container will be limited to use if not
specified. |
11 |
The default amount of memory that a container will be limited to use if not specified. |
12 |
The default amount of CPU that a container will request to use if not specified. |
13 |
The default amount of memory that a container will request to use if not specified. |
14 |
The maximum amount of CPU burst that a container can make as a ratio of its limit over request. |
Example 2. OpenShift Origin Limit Range Object Definition
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)
1 |
The maximum size of an image that can be pushed to an internal registry. |
2 |
The maximum number of unique image tags per image stream’s spec. |
3 |
The maximum number of unique image references per image stream’s status. |
Both core and OpenShift Origin resources can be specified in just one limit range
object. They are separated here into two examples for clarity.
Container Limits
Per container, the following must hold true if specified:
Table 1. Container
Constraint |
Behavior |
|
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. A limit value does not need to be specified.
|
|
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[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,
OpenShift Origin calculates a limit to request ratio by dividing the limit by the
request.
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 .
|
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
Across all containers in a pod, the following must hold true:
Table 2. Pod
Constraint |
Enforced Behavior |
|
Min[resource] less than or equal to container.resources.requests[resource]
(required) less than or equal to container.resources.limits[resource]
(optional)
|
|
container.resources.limits[resource] (required) less than or equal to
Max[resource]
|
|
MaxLimitRequestRatio[resource] less than or equal to (
container.resources.limits[resource] /
container.resources.requests[resource] )
|
Image Limits
Per image, the following must hold true if specified:
Table 3. Image
Constraint |
Behavior |
|
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. To update older
deployment configuration, refer to
Enforcing
quota in the Registry.
|
|
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.
|
Image Stream Limits
-
openshift.io/image-tags
-
openshift.io/images
Per image stream, the following must hold true if specified:
Table 4. ImageStream
Constraint |
Behavior |
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.
|
|
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 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
Across all persistent volume claims in a project, the following must hold true:
Table 5. Pod
Constraint |
Enforced Behavior |
|
Min[resource] ⇐ claim.spec.resources.requests[resource] (required)
|
|
claim.spec.resources.requests[resource] (required) ⇐ Max[resource]
|
Example 3. Limit Range Object Definition
{
"apiVersion": "v1",
"kind": "LimitRange",
"metadata": {
"name": "pvcs" (1)
},
"spec": {
"limits": [{
"type": "PersistentVolumeClaim",
"min": {
"storage": "2Gi" (2)
},
"max": {
"storage": "50Gi" (3)
}
}
]
}
}
1 |
The name of the limit range object. |
2 |
The minimum amount of storage that can be requested in a persistent volume claim |
3 |
The maximum amount of storage that can be requested in a persistent volume claim |