Resource Management for Pods and Containers [page]deterministic

concepts

When you specify a [pod](#gloss:pod), you can optionally specify how much of each resource a [container](#gloss:container) needs. The most common resources to specify are CPU and memory (RAM); there are others.

When you specify the resource _request_ for containers in a Pod, the [kube-scheduler](#gloss:kube-scheduler) uses this information to decide which node to place the Pod on. When you specify a resource _limit_ for a container, the [kubelet](#gloss:kubelet) enforces those limits so that the running container is not allowed to use more of that resource than the limit you set. The kubelet also reserves at least the _request_ amount of that system resource specifically for that container to use.

## Requests and limits

If the node where a Pod is running has enough of a resource available, it's possible (and allowed) for a container to use more resource than its `request` for that resource specifies.

For example, if you set a `memory` request of 256 MiB for a container, and that container is in a Pod scheduled to a Node with 8GiB of memory and no other Pods, then the container can try to use more RAM.

Limits are a different story. Both `cpu` and `memory` limits are applied by the kubelet (and [container runtime](#gloss:container-runtime)), and are ultimately enforced by the kernel. On Linux nodes, the Linux kernel enforces limits with [cgroups](#gloss:cgroup). The behavior of `cpu` and `memory` limit enforcement is slightly different.

`cpu` limits are enforced by CPU throttling. When a container approaches its `cpu` limit, the kernel will restrict access to the CPU corresponding to the container's limit. Thus, a `cpu` limit is a hard limit the kernel enforces. Containers may not use more CPU than is specified in their `cpu` limit.

`memory` limits are enforced by the kernel with out of memory (OOM) kills. When a container uses more than its `memory` limit, the kernel may terminate it. However, terminations only happen when the kernel detects memory pressure. Thus, a container that over allocates memory may not be immediately killed. This means `memory` limits are enforced reactively. A container may use more memory than its `memory` limit, but if it does, it may get killed.

> Note: There is an alpha feature `MemoryQoS` which adds memory throttling and optional tiered memory reservation on Linux nodes using cgroup v2. For details, see [Memory QoS with cgroup v2](/docs/concepts/workloads/pods/pod-qos/#memory-qos-with-cgroup-v2).

> Note: If you specify a limit for a resource, but do not specify any request, and no admission-time mechanism has applied a default request for that resource, then Kubernetes copies the limit you specified and uses it as the requested value for the resource.

## Resource types

A *resource type* has a base unit and can be requested, limited, or both. Kubernetes has the following built-in resource types:

| Resource type | Description | Base unit | |---|---|---| | `cpu` | Compute processing | cpu (core) | | `memory` | RAM | Bytes | | `ephemeral-storage` | [Local ephemeral storage](/docs/concepts/storage/ephemeral-storage/) | Bytes | | `hugepages-<size>` | [Huge pages](#huge-pages) (Linux only) | Bytes |

Clusters can also provide [extended resources](/docs/concepts/configuration/manage-resources-containers/#extended-resources) (resources with a custom name, typically exposed by device plugins).

### Huge pages

For Linux workloads, you can specify _huge page_ resources. Huge pages are a Linux-specific feature where the node kernel allocates blocks of memory that are much larger than the default page size.

For example, on a system where the default page size is 4KiB, you could specify a limit, `hugepages-2Mi: 80Mi`. If the container tries allocating over 40 2MiB huge pages (a total of 80 MiB), that allocation fails.

> Note: You cannot overcommit `hugepages-*` resources. This is different from the `memory` and `cpu` resources.

CPU and memory are collectively referred …(trimmed)