Resource Quotas [page]deterministic

When several users or teams share a cluster with a fixed number of nodes, there is a concern that one team could use more than its fair share of resources.

_Resource quotas_ are a tool for administrators to address this concern.

A resource quota, defined by a ResourceQuota object, provides constraints that limit aggregate resource consumption per [namespace](#gloss:namespace). A ResourceQuota can also limit the [quantity of objects that can be created in a namespace](#quota-on-object-count) by API kind, as well as the total amount of [infrastructure resources](#gloss:infrastructure-resource) that may be consumed by API objects found in that namespace.

> Caution: Neither contention nor changes to quota will affect already created resources.

## How Kubernetes ResourceQuotas work

ResourceQuotas work like this:

• Different teams work in different namespaces. This separation can be enforced with [RBAC](/docs/reference/access-authn-authz/rbac/) or any other [authorization](/docs/reference/access-authn-authz/authorization/) mechanism.

• A cluster administrator creates at least one ResourceQuota for each namespace. - To make sure the enforcement stays enforced, the cluster administrator should also restrict access to delete or update that ResourceQuota; for example, by defining a [ValidatingAdmissionPolicy](/docs/reference/access-authn-authz/validating-admission-policy/).

• Users create resources (pods, services, etc.) in the namespace, and the quota system tracks usage to ensure it does not exceed hard resource limits defined in a ResourceQuota.

You can apply a [scope](#quota-scopes) to a ResourceQuota to limit where it applies,

• If creating or updating a resource violates a quota constraint, the control plane rejects that request with HTTP status code `403 Forbidden`. The error includes a message explaining the constraint that would have been violated.

• If quotas are enabled in a namespace for [resource](#gloss:infrastructure-resource) such as `cpu` and `memory`, users must specify requests or limits for those values when they define a Pod; otherwise, the quota system may reject pod creation.

The resource quota [walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) shows an example of how to avoid this problem.

> Note: * You can define a [LimitRange](/docs/concepts/policy/limit-range/) to force defaults on pods that make no compute resource requirements (so that users don't have to remember to do that).

You often do not create Pods directly; for example, you more usually create a [workload management](/docs/concepts/workloads/controllers/) object such as a [deployment](#gloss:deployment). If you create a Deployment that tries to use more resources than are available, the creation of the Deployment (or other workload management object) succeeds, but the Deployment may not be able to get all of the Pods it manages to exist. In that case you can check the status of the Deployment, for example with `kubectl describe`, to see what has happened.

• For `cpu` and `memory` resources, ResourceQuotas enforce that every (new) pod in that namespace sets a limit for that resource. If you enforce a resource quota in a namespace for either `cpu` or `memory`, you and other clients, must specify either `requests` or `limits` for that resource, for every new Pod you submit. If you don't, the control plane may reject admission for that Pod.
• For other resources: ResourceQuota works and will ignore pods in the namespace without setting a limit or request for that resource. It means that you can create a new pod without limit/request for ephemeral storage if the resource quota limits the ephemeral storage of this namespace.

You can use a [LimitRange](/docs/concepts/policy/limit-range/) to automatically set a default request for these resources.

The name of a ResourceQuota object must be a valid [DNS subdomain name](/docs/concepts/ …(trimmed)