Kubernetes ephemeral volumes provide temporary storage tied directly to a pod’s lifespan. Applications can use scratch space, caches or read-only input without long-term retention. Multiple volume types and CSI support deliver on-demand provisioning, capacity controls and secure access for event-driven flows.
TL;DR
- They live and die with pods; no data persists beyond pod deletion.
- Supports emptyDir (disk or memory), ConfigMap, Secret, DownwardAPI, Projected and CSI inline.
- CSI ephemeral volumes provision via StorageClass or inline attributes; auto-cleanup on pod exit.
- Counts against resource quotas for storageRequests; snapshots rarely used for ephemeral data.
- Ideal for caches, scratch space, CI pipelines and event-driven microservices buffering.
Ephemeral Volumes Overview
These volumes attach storage directly to a pod. Kubernetes manages lifecycle: volume provisioning upon pod startup and cleanup on deletion. No manual teardown needed.
Ephemeral Volumes Lifecycle
When the kubelet creates a pod, it provisions each defined ephemeral volume. It mounts the volume into the container. On pod termination, kubelet unmounts and deletes the backing storage. No leftover artifacts remain unless explicitly backed by a PersistentVolumeClaim template.
Ephemeral Volumes Types
emptyDir and memory-backed emptyDir
emptyDir creates a directory on node disk by default. Set medium: "Memory" for a tmpfs mount in RAM.
apiVersion: v1
kind: Pod
metadata:
name: scratch-pod
spec:
containers:
- name: app
image: busybox
volumeMounts:
- mountPath: /scratch
name: scratch-vol
volumes:
- name: scratch-vol
emptyDir:
medium: "Memory" # RAM-based tmpfs
ConfigMap, Secret, DownwardAPI, Projected
Read-only data mounts for configuration, credentials or metadata.
volumes:
- name: cfg
configMap:
name: app-config
- name: creds
secret:
secretName: app-secret
- name: podinfo
downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- name: combined
projected:
sources:
- configMap:
name: app-config
- secret:
name: app-secret
CSI Ephemeral Volumes
CSI drivers can provision inline ephemeral volumes. Set volumeAttributes: { 'ephemeral': 'true' }. Kubernetes skips PVC objects and cleans up on pod delete.
volumes:
- name: csi-ephemeral
csi:
driver: csi.example.com
volumeAttributes:
ephemeral: "true"
Provisioning and Capacity
emptyDir requires no provisioning. CSI inline volumes use the StorageClass tied to the driver. PersistentVolumeClaim templates in StatefulSets can create ephemeral PVCs dynamically with desired capacity.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: cache-ss
spec:
serviceName: "cache"
replicas: 3
selector:
matchLabels:
app: cache
template:
metadata:
labels:
app: cache
spec:
containers:
- name: cache
image: redis
volumeMounts:
- name: data
mountPath: /data
volumeClaimTemplates:
- metadata:
name: data
spec:
storageClassName: fast-ephemeral
resources:
requests:
storage: 10Gi
Access Controls and Security Contexts
Define fsGroup, runAsUser or SELinux labels in pod securityContext. Combine with RBAC for secret/configMap mounts. CSI drivers may enforce additional policies via volumeContext.
Resource Quotas and Snapshot Considerations
Kubernetes counts inline ephemeral CSI volumes and PVC templates against storage resource quotas (spec.hard.requests.storage). Standard VolumeSnapshot APIs apply only if snapshotClass and CSI driver support it, but ephemerals seldom need snapshots.
Use-Cases
These type of volumes excel for:
- Caching layers in web servers or databases.
- Scratch space in CI/CD jobs or batch analytics.
- Ephemeral containers for debugging live systems.
- Buffering messages in event-driven microservices before acknowledgements.
References
- Kubernetes official documentation
- CSI Ephemeral Inline Volumes
- Resource Quotas | Kubernetes
- Volume Snapshots | Kubernetes
Suggested Reading
PostHashID: 165da0494c8b669951ae19e07094093b40f6ae7fa6d643a7600ac7d2a337de24
