Local ephemeral storage [page]deterministic
Nodes have local ephemeral storage, backed by locally-attached writeable devices or, sometimes, by RAM. "Ephemeral" means that there is no long-term guarantee about durability.
Pods use ephemeral local storage for scratch space, caching, and for logs. The kubelet can provide scratch space to Pods using local ephemeral storage to mount [`emptyDir`](/docs/concepts/storage/volumes/#emptydir) [volumes](#gloss:volume) into containers.
The kubelet also uses this kind of storage to hold [node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level), container images, and the writable layers of running containers.
> Caution: If a node fails, the data in its ephemeral storage can be lost. Your applications cannot expect any performance SLAs (disk IOPS for example) from local ephemeral storage.
> Note: To make the resource quota work on ephemeral-storage, two things need to be done:
* An admin sets the resource quota for ephemeral-storage in a namespace. * A user needs to specify limits for the ephemeral-storage resource in the Pod spec.
If the user doesn't specify the ephemeral-storage resource limit in the Pod spec, the resource quota is not enforced on ephemeral-storage.
Kubernetes lets you track, reserve and limit the amount of ephemeral local storage a Pod can consume.
## Configurations for local ephemeral storage {#configurations}
Kubernetes supports the following ways to configure local ephemeral storage on a node:
In this configuration, you place all different kinds of ephemeral local data (`emptyDir` volumes, writeable layers, container images, logs) into one filesystem.
The kubelet also writes [node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) and treats these similarly to ephemeral local storage.
The kubelet writes logs to files inside its configured log directory (`/var/log` by default); and has a base directory for other locally stored data (`/var/lib/kubelet` by default).
Typically, both `/var/lib/kubelet` and `/var/log` are on the system root filesystem, and the kubelet is designed with that layout in mind.
Your node can have as many other filesystems, not used for Kubernetes, as you like.
You use one filesystem on the node for ephemeral data from running Pods, such as logs and `emptyDir` volumes. You can also use this filesystem for other data, such as system logs that are not related to Kubernetes; it can even be the root filesystem.
The kubelet also writes [node-level container logs](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) into the first filesystem, and treats these similarly to ephemeral local storage.
You also use a separate filesystem, backed by a different logical storage device. In this configuration, the container runtime stores both container image layers and writeable layers on this second filesystem. Configure this storage location in your container runtime, not in the kubelet.
The first filesystem does not hold any image layers or writeable layers.
Your node can have as many other filesystems, not used for Kubernetes, as you like.
In this configuration, container image layers are on a separate filesystem, and container writeable layers are on the same filesystem as the kubelet's ephemeral data, such as logs and `emptyDir` volumes.
This layout requires support for the `containerfs` eviction signals. For details about the feature gate and the container runtimes that support this layout, see [node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/#filesystem-signals).
The [node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/#filesystem-signals) page refers to these observed filesystems as `nodefs`, `imagefs`, and `containerfs`. Those names do not always mean separate mount points.
The kubelet can measure local storage use when you set up the node using one of the supported configurations for lo …(trimmed)