Limit Ranges

A LimitRange provides constraints that can:

• Enforce minimum and maximum compute resources usage per Pod or Container in a namespace.
• Enforce minimum and maximum storage request per PersistentVolumeClaim in a namespace.
• Enforce a ratio between request and limit for a resource in a namespace.

LimitRange support has been enabled by default since Kubernetes 1.10.

The name of a LimitRange object must be a valid DNS subdomain name.

• The administrator creates one LimitRange in one namespace.
• Users create resources like Pods, Containers, and PersistentVolumeClaims in the namespace.
• The admission controller enforces defaults and limits for all Pods and Containers that do not set compute resource requirements and tracks usage to ensure it does not exceed resource minimum, maximum and ratio defined in any LimitRange present in the namespace.
• If creating or updating a resource (Pod, Container, PersistentVolumeClaim) that violates a LimitRange constraint, the request to the API server will fail with an HTTP status code and a message explaining the constraint that have been violated.
• If a LimitRange is activated in a namespace for compute resources like and , users must specify requests or limits for those values. Otherwise, the system may reject Pod creation.
• LimitRange validations occurs only at Pod Admission stage, not on Running Pods.

Examples of policies that could be created using limit range are:

• Define default CPU limit and request to 150m and memory default request to 300Mi for Containers started with no cpu and memory requests in their specs.

Neither contention nor changes to a LimitRange will affect already created resources.

What’s next

Refer to the LimitRanger design document for more information.

• .
• how to configure minimum and maximum Memory constraints per namespace.
• .
• how to configure default Memory Requests and Limits per namespace.
• .