A limit range, defined by a LimitRange object, restricts resource
consumption in a project. In the project you can set specific resource
limits for a pod, container, image, image stream, or
persistent volume claim (PVC).
All requests to create and modify resources are evaluated against each
LimitRange object in the project. If the resource violates any of the
enumerated constraints, the resource is rejected.
The following shows a limit range object for all components: pod, container,
image, image stream, or PVC. You can configure limits for any or all of these
components in the same object. You create a different limit range object for
each project where you want to control resources.
Sample limit range object for a container
apiVersion: "v1"
kind: "LimitRange"
metadata:
name: "resource-limits"
spec:
limits:
- type: "Container"
max:
cpu: "2"
memory: "1Gi"
min:
cpu: "100m"
memory: "4Mi"
default:
cpu: "300m"
memory: "200Mi"
defaultRequest:
cpu: "200m"
memory: "100Mi"
maxLimitRequestRatio:
cpu: "10"
About component limits
The following examples show limit range parameters for each component. The
examples are broken out for clarity. You can create a single LimitRange object
for any or all components as necessary.
Container limits
A limit range allows you to specify the minimum and maximum CPU and memory that each container
in a pod can request for a specific project. If a container is created in the project,
the container CPU and memory requests in the Pod spec must comply with the values set in the
LimitRange object. If not, the pod does not get created.
-
The container CPU or memory request and limit must be greater than or equal to the
min resource constraint for containers that are specified in the LimitRange object.
-
The container CPU or memory request and limit must be less than or equal to the
max resource constraint for containers that are specified in the LimitRange object.
If the LimitRange object defines a max CPU, you do not need to define a CPU
request value in the Pod spec. But you must specify a CPU limit value that
satisfies the maximum CPU constraint specified in the limit range.
-
The ratio of the container limits to requests must be
less than or equal to the maxLimitRequestRatio value for containers that
is specified in the LimitRange object.
If the LimitRange object defines a maxLimitRequestRatio constraint, any new
containers must have both a request and a limit value. OKD
calculates the 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, the limit-to-request ratio for cpu is
5. This ratio must be less than or equal to the maxLimitRequestRatio.
If the Pod spec does not specify a container resource memory or limit,
the default or defaultRequest CPU and memory values for containers
specified in the limit range object are assigned to the container.
Container LimitRange object definition
apiVersion: "v1"
kind: "LimitRange"
metadata:
name: "resource-limits" (1)
spec:
limits:
- type: "Container"
max:
cpu: "2" (2)
memory: "1Gi" (3)
min:
cpu: "100m" (4)
memory: "4Mi" (5)
default:
cpu: "300m" (6)
memory: "200Mi" (7)
defaultRequest:
cpu: "200m" (8)
memory: "100Mi" (9)
maxLimitRequestRatio:
cpu: "10" (10)
| 1 |
The name of the LimitRange object. |
| 2 |
The maximum amount of CPU that a single container in a pod can request. |
| 3 |
The maximum amount of memory that a single container in a pod can request. |
| 4 |
The minimum amount of CPU that a single container in a pod can request. |
| 5 |
The minimum amount of memory that a single container in a pod can request. |
| 6 |
The default amount of CPU that a container can use if not specified in the Pod spec. |
| 7 |
The default amount of memory that a container can use if not specified in the Pod spec. |
| 8 |
The default amount of CPU that a container can request if not specified in the Pod spec. |
| 9 |
The default amount of memory that a container can request if not specified in the Pod spec. |
| 10 |
The maximum limit-to-request ratio for a container. |
Pod limits
A limit range allows you to specify the minimum and maximum CPU and memory limits for all containers
across a pod in a given project. To create a container in the project, the container CPU and memory
requests in the Pod spec must comply with the values set in the LimitRange object. If not,
the pod does not get created.
If the Pod spec does not specify a container resource memory or limit,
the default or defaultRequest CPU and memory values for containers
specified in the limit range object are assigned to the container.
Across all containers in a pod, the following must hold true:
-
The container CPU or memory request and limit must be greater than or equal to the
min resource constraints for pods that are specified in the LimitRange object.
-
The container CPU or memory request and limit must be less than or equal to the
max resource constraints for pods that are specified in the LimitRange object.
-
The ratio of the container limits to requests must be less than or equal to
the maxLimitRequestRatio constraint specified in the LimitRange object.
Pod LimitRange object definition
apiVersion: "v1"
kind: "LimitRange"
metadata:
name: "resource-limits" (1)
spec:
limits:
- type: "Pod"
max:
cpu: "2" (2)
memory: "1Gi" (3)
min:
cpu: "200m" (4)
memory: "6Mi" (5)
maxLimitRequestRatio:
cpu: "10" (6)
| 1 |
The name of the limit range object. |
| 2 |
The maximum amount of CPU that a pod can request across all containers. |
| 3 |
The maximum amount of memory that a pod can request across all containers. |
| 4 |
The minimum amount of CPU that a pod can request across all containers. |
| 5 |
The minimum amount of memory that a pod can request across all containers. |
| 6 |
The maximum limit-to-request ratio for a container. |
Image limits
A LimitRange object allows you to specify the maximum size of an image
that can be pushed to an OpenShift image registry.
When pushing images to an OpenShift image registry, the following must hold true:
Image LimitRange object definition
apiVersion: "v1"
kind: "LimitRange"
metadata:
name: "resource-limits" (1)
spec:
limits:
- type: openshift.io/Image
max:
storage: 1Gi (2)
| 1 |
The name of the LimitRange object. |
| 2 |
The maximum size of an image that can be pushed to an OpenShift image registry. |
|
|
To prevent blobs that exceed the limit from being uploaded to the registry, the
registry must be configured to enforce quotas.
|
|
|
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 is converted by the registry to schema v1 lacking all
the size information. No storage limit set on images prevent it from being
uploaded.
|
Image stream limits
A LimitRange object allows you to specify limits for image streams.
For each image stream, the following must hold true:
-
The number of image tags in an ImageStream specification must be less
than or equal to the openshift.io/image-tags constraint in the LimitRange object.
-
The number of unique references to images in an ImageStream specification
must be less than or equal to the openshift.io/images constraint in the limit
range object.
Imagestream LimitRange object definition
apiVersion: "v1"
kind: "LimitRange"
metadata:
name: "resource-limits" (1)
spec:
limits:
- type: openshift.io/ImageStream
max:
openshift.io/image-tags: 20 (2)
openshift.io/images: 30 (3)
| 1 |
The name of the LimitRange object. |
| 2 |
The maximum number of unique image tags in the imagestream.spec.tags
parameter in imagestream spec. |
| 3 |
The maximum number of unique image references in the imagestream.status.tags
parameter in the imagestream spec. |
The openshift.io/image-tags resource represents unique image
references. Possible references are an ImageStreamTag, an
ImageStreamImage and a DockerImage. Tags can be created using
the oc tag and oc import-image commands. No distinction
is made between internal and external references. However, each unique reference
tagged in an ImageStream 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.
The openshift.io/images resource represents unique image names recorded in
image stream status. It allows for restriction of a number of images that can be
pushed to the OpenShift image registry. Internal and external references are not
distinguished.
Persistent volume claim limits
A LimitRange object allows you to restrict the storage requested in a persistent volume claim (PVC).
Across all persistent volume claims in a project, the following must hold true:
-
The resource request in a persistent volume claim (PVC) must be greater than or equal
the min constraint for PVCs that is specified in the LimitRange object.
-
The resource request in a persistent volume claim (PVC) must be less than or equal
the max constraint for PVCs that is specified in the LimitRange object.
PVC LimitRange object definition
apiVersion: "v1"
kind: "LimitRange"
metadata:
name: "resource-limits" (1)
spec:
limits:
- type: "PersistentVolumeClaim"
min:
storage: "2Gi" (2)
max:
storage: "50Gi" (3)
| 1 |
The name of the LimitRange 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. |