Ephemeral storage in Kubernetes provides temporary disk space for pods to store transient data like logs, caches, and scratch space. Unlike persistent volumes, this storage is tied directly to the pod’s lifecycle—meaning once a pod is deleted or moved, the data is permanently erased. Mastering ephemeral storage is key to preventing pod evictions and ensuring stable resource management within your cluster.
Key takeaways
- Ephemeral storage is temporary storage tied to a pod’s lifecycle in Kubernetes.
- Local ephemeral storage is managed at the node level and includes container writable layers, logs, and emptyDir volumes.
- You can define ephemeral storage requests and limits in a pod spec to avoid resource conflicts and pod evictions.
- Ephemeral volumes are ideal for scratch space, cached files, and transient data generated during temporary data processing.
- Unlike persistent volumes, ephemeral storage does not provide long term storage or data persistence.
Table of contents
- Ephemeral storage in Kubernetes is temporary
- The age of containers and cloud-native workloads
- How containers use storage
- What is local ephemeral storage?
- Types of ephemeral storage volumes Kubernetes supports
- Ephemeral storage requests and limits
- Ephemeral storage versus persistent storage
- Use cases for ephemeral storage
- Limitations and data loss risks
- Best practices for managing ephemeral storage usage
- Building scalable, cloud-native applications without managing infrastructure overhead
- FAQs
- Related resources
Ephemeral storage in Kubernetes is temporary
Ephemeral storage refers to temporary storage that exists only for the lifetime of a pod in Kubernetes. When a pod is deleted, restarted on another node, or evicted due to resource pressure, the ephemeral data stored in that pod is removed. In Kubernetes specifically, ephemeral storage includes data stored in:
- Container image layers.
- Writable layers.
- The root filesystem.
- emptyDir volumes.
- Node level logs.
- Pod-specific metadata.
Ephemeral storage is managed locally on the node's root disk or primary filesystem, and because its pod-specific metadata and scratch data are tied to running containers, it should never be used for critical data that requires durability.
In simple terms, ephemeral storage is temporary storage tied directly to a pod's lifecycle.
The age of containers and cloud-native workloads
Modern cloud infrastructure ranges from virtual machines that emulate hardware and include a full guest operating system to containers that share the host kernel and add only the file system and application dependencies required to run.
Containers rely on a container runtime to manage container image layers and writable layers. Because containers package an app image with consistent dependencies, running containers behave predictably across multiple nodes. This eliminates environment drift and reduces operational overhead.
Cloud-native platforms also simplify resource scaling and storage usage. Teams can define resource requests, ephemeral storage requests, and requests and limits directly at the pod specification.
How containers use storage
Every application uses data. Containers access data through:
- Network calls using HTTP or RPC.
- Databases such as MongoDB.
- Volumes mounted from local storage or cloud storage.
In Kubernetes, volumes determine whether data stored is temporary storage or persistent storage.
Persistent storage
Persistent storage uses persistent volumes and persistent volume claims. Unlike persistent volumes, ephemeral storage does not survive pod restarts or node failures. Persistent volumes provide long-term storage and guaranteed data persistence. Persistent storage is required for critical data, stateful workloads, and databases.
Temporary or ephemeral storage
Ephemeral storage is temporary storage used for scratch data, cached files, computation results, and transient data generated during application runtime. It is managed locally and tied to the pod lifecycle.
What is local ephemeral storage?
Local ephemeral storage refers to the disk space consumed on the node's root filesystem. This includes:
- Container image layers.
- Writable layers.
- EmptyDir volumes.
- Node-level logs.
- Pod-specific metadata.
Because local ephemeral storage resides on the root disk or primary filesystem rather than a separate disk by default, disk usage must be carefully monitored.
Excessive ephemeral storage can cause pod evictions. Cluster administrators often define thresholds based on disk iOPS, byte quantities, and overall pod storage limit values.
Types of ephemeral storage volumes Kubernetes supports
Kubernetes supports several ephemeral volumes Kubernetes clusters can provision.
emptyDir volumes
An emptyDir volume is created at pod startup and deleted when the pod is removed. Data stored in emptyDir volumes persists across container restarts within the same pod, but is lost if the pod is restarted.
emptyDir volumes are commonly used for scratch space, scratch data, cached files, and temporary data processing.
ConfigMap, downwardAPI, and secret volumes
These volumes inject configuration data and Kubernetes data into running containers.
- ConfigMaps store non-confidential, configuration data in key-value pairs, as can be seen in the example configuration below:
- Secret volumes store sensitive data, such as passwords or API keys. Secrets are stored as base64 strings in configuration files:
Generic ephemeral volumes
Generic ephemeral volumes are dynamically provisioned volumes defined inline in the pod spec. They rely on storage drivers that also support persistent volumes. Generic ephemeral volumes provide isolation without requiring long-term storage. They are useful for temporary data processing workloads.
An example of an ephemeral volume that takes up to 4GB of space would be:
CSI ephemeral volumes
CSI ephemeral volumes are provided by container storage interface drivers, which can provision dynamically without creating persistent volume claims.
Ephemeral storage requests and limits
To prevent resource conflicts, Kubernetes allows you to configure ephemeral storage requests and limits within a pod specification.
- Ephemeral storage requests specify the amount of local ephemeral storage a container expects to use.
- Ephemeral storage limits define the maximum storage usage allowed.
If ephemeral storage usage exceeds defined limits, Kubernetes may trigger pod evictions. This protects other scheduled containers and preserves node stability.
Ephemeral storage usage and pod evictions
Kubernetes tracks ephemeral storage usage along with CPU and memory as part of overall resource requests.
When disk usage crosses configured thresholds, the kubelet may initiate pod evictions. Pod evictions occur when the overall pod storage limit or node level disk pressure exceeds acceptable limits. Because ephemeral local storage is managed locally, uncontrolled storage usage can impact unrelated workloads on the same node.
Monitoring disk usage, logging agents, and storage usage metrics helps avoid unexpected disruptions.
Ephemeral storage versus persistent storage
Understanding the differences between ephemeral storage and persistent storage is essential.
Unlike persistent volumes, ephemeral storage offers no durability guarantees.
Use cases for ephemeral storage
Ephemeral storage is appropriate for:
- Scratch space.
- Scratch data.
- Cached files.
- Session data.
- Temporary data processing.
- Transient data generated during batch jobs.
- Computation results.
Ephemeral volumes Kubernetes’ supports are particularly useful when workloads can safely regenerate data. However, ephemeral storage should not be used for:
- Critical data.
- Long-term storage.
- Real-time data that requires guaranteed persistence.
Limitations and data loss risks
The primary limitation of ephemeral storage is data loss. When pods are deleted, rescheduled, or evicted, ephemeral data is permanently removed. This includes transient data, cached files, and session data.
Additional limitations include:
- Dependence on the root disk.
- Risk of pod evictions under heavy disk usage.
- No guarantees for sensitive data durability.
Developers should design workloads so temporary data can be safely regenerated.
Best practices for managing ephemeral storage
Cluster administrators and platform engineers should:
- Define clear ephemeral storage requests and limits in every pod spec.
- Monitor ephemeral storage usage and overall pod storage limit values.
- Rotate node-level logs using logging agents.
- Avoid storing critical data in ephemeral volumes.
- Separate persistent volumes from ephemeral local storage.
- Monitor disk iOPS and byte quantities.
- Validate resource requests before deploying scheduled containers.
Following these practices reduces resource conflicts and prevents cascading failures.
Building scalable, cloud-native applications without managing infrastructure overhead
Applications can run on in-premises servers or in virtual machines in the cloud. On-premises infrastructure requires teams to manage hardware, software, updates, security patches, and capacity planning. Cloud-based virtual machines reduce some of that burden. But scaling and maintaining consistent configurations across environments can still be complex and resource-intensive.
Containers simplify this model by packaging applications and dependencies into portable, reproducible units—and this makes deployment, horizontal scaling, and configuration replication significantly easier. Teams can run and manage MongoDB containers in their preferred cloud provider with predictable and streamlined operations.
MongoDB Atlas extends these benefits by delivering a fully managed database service that integrates seamlessly with containerized applications, removing operational overhead while enabling teams to access, scale, and manage their data securely and efficiently in the cloud.