Limit Ranges [page]deterministic

By default, containers run with unbounded [compute resources](/docs/concepts/configuration/manage-resources-containers/) on a Kubernetes cluster. Using Kubernetes [resource quotas](/docs/concepts/policy/resource-quotas/), administrators (also termed _cluster operators_) can restrict consumption and creation of cluster resources (such as CPU time, memory, and persistent storage) within a specified [namespace](#gloss:namespace). Within a namespace, a [Pod](#gloss:Pod) can consume as much CPU and memory as is allowed by the ResourceQuotas that apply to that namespace. As a cluster operator, or as a namespace-level administrator, you might also be concerned about making sure that a single object cannot monopolize all available resources within a namespace.

A LimitRange is a policy to constrain the resource allocations (limits and requests) that you can specify for each applicable object kind (such as Pod or [PersistentVolumeClaim](#gloss:persistent-volume-claim)) in a namespace.

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](#gloss:persistent-volume-claim) in a namespace.
• Enforce a ratio between request and limit for a resource in a namespace.
• Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime.

Kubernetes constrains resource allocations to Pods in a particular namespace whenever there is at least one LimitRange object in that namespace.

The name of a LimitRange object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).

## Constraints on resource limits and requests

• The administrator creates a LimitRange in a namespace.
• Users create (or try to create) objects in that namespace, such as Pods or PersistentVolumeClaims.
• First, the LimitRange admission controller applies default request and limit values for all Pods (and their containers) that do not set compute resource requirements.
• Second, the LimitRange tracks usage to ensure it does not exceed resource minimum, maximum and ratio defined in any LimitRange present in the namespace.
• If you attempt to create or update an object (Pod or PersistentVolumeClaim) that violates a LimitRange constraint, your request to the API server will fail with an HTTP status code `403 Forbidden` and a message explaining the constraint that has been violated.
• If you add a LimitRange in a namespace that applies to compute-related resources such as `cpu` and `memory`, you must specify requests or limits for those values. Otherwise, the system may reject Pod creation.
• LimitRange validations occur only at Pod admission stage, not on running Pods. If you add or modify a LimitRange, the Pods that already exist in that namespace continue unchanged.
• If two or more LimitRange objects exist in the namespace, it is not deterministic which default value will be applied.

## LimitRange and admission checks for Pods

A LimitRange does not check the consistency of the default values it applies. This means that a default value for the _limit_ that is set by LimitRange may be less than the _request_ value specified for the container in the spec that a client submits to the API server. If that happens, the final Pod will not be schedulable.

For example, you define a LimitRange with below manifest:

> Note: The following examples operate within the default namespace of your cluster, as the namespace parameter is undefined and the LimitRange scope is limited to the namespace level. This implies that any references or operations within these examples will interact with elements within the default namespace of your cluster. You can override the operating namespace by configuring namespace in the `metadata.namespace` field.

along with a Pod that declares a CPU resource reques …(trimmed)