Ephemeral Volumes

Ephemeral volumes are temporary storage that exists only for the lifetime of a pod. When the pod is deleted, all data in ephemeral volumes is lost. These volumes are perfect for temporary files, caching, sharing data between containers in the same pod, or providing configuration and secrets to containers.

What are Ephemeral Volumes?

Ephemeral volumes share the lifecycle of their pod. They’re created when the pod starts and destroyed when the pod terminates. Unlike persistent volumes, ephemeral volumes don’t survive pod restarts or deletions.

Common Ephemeral Volume Types

emptyDir

An emptyDir volume is created when a pod is assigned to a node and exists as long as that pod is running on that node. The volume starts empty and is shared between all containers in the pod.

Use cases:

• Temporary scratch space
• Caching files
• Checkpointing data
• Sharing data between containers in a pod

Example:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-cache
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: cache
      mountPath: /tmp/cache
  - name: sidecar
    image: busybox
    volumeMounts:
    - name: cache
      mountPath: /cache
  volumes:
  - name: cache
    emptyDir: {}

With size limit:

volumes:
- name: cache
  emptyDir:
    sizeLimit: 500Mi  # Limit the cache size

With memory-backed storage (tmpfs):

volumes:
- name: cache
  emptyDir:
    medium: Memory  # Stores data in RAM (faster, but limited)
    sizeLimit: 100Mi

configMap

A configMap volume makes ConfigMap data available as files in a directory. The volume is read-only, and files are automatically updated when the ConfigMap changes (though applications may need to reload configuration).

Use cases:

• Configuration files
• Application settings
• Environment-specific configs

Example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  app.properties: |
    server.port=8080
    debug=true
  logging.conf: |
    level=INFO
---
apiVersion: v1
kind: Pod
metadata:
  name: app-with-config
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: config
      mountPath: /etc/config
  volumes:
  - name: config
    configMap:
      name: app-config

This creates files at /etc/config/app.properties and /etc/config/logging.conf with the contents from the ConfigMap.

Mounting specific keys:

volumes:
- name: config
  configMap:
    name: app-config
    items:
    - key: app.properties
      path: application.properties  # Custom filename

secret

A secret volume makes Secret data available as files in a directory. Like ConfigMap volumes, secret volumes are read-only. The data is automatically base64 decoded.

Use cases:

• TLS certificates
• API keys
• Database passwords
• Authentication tokens

Example:

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=  # base64 encoded
  password: cGFzc3dvcmQ=
---
apiVersion: v1
kind: Pod
metadata:
  name: app-with-secrets
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: secrets
      mountPath: /etc/secrets
      readOnly: true
  volumes:
  - name: secrets
    secret:
      secretName: db-credentials

This creates files at /etc/secrets/username and /etc/secrets/password with the decoded values.

With custom file permissions:

volumes:
- name: secrets
  secret:
    secretName: db-credentials
    defaultMode: 0400  # Read-only for owner only

downwardAPI

A downwardAPI volume exposes pod and container field values as files. This is useful when containers need metadata about themselves.

Available fields:

• Pod metadata (name, namespace, UID)
• Pod labels and annotations
• Container resource limits and requests
• Node name and IP

Example:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-metadata
  labels:
    app: myapp
    version: v1
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: podinfo
      mountPath: /etc/podinfo
  volumes:
  - name: podinfo
    downwardAPI:
      items:
      - path: "labels"
        fieldRef:
          fieldPath: metadata.labels
      - path: "annotations"
        fieldRef:
          fieldPath: metadata.annotations
      - path: "name"
        fieldRef:
          fieldPath: metadata.name
      - path: "cpu_limit"
        resourceFieldRef:
          containerName: app
          resource: limits.cpu

Ephemeral Volume Lifecycle

When to Use Ephemeral Volumes

Use ephemeral volumes when:

✅ Data is temporary - Cache files, temporary downloads, scratch space
✅ Data is regenerable - Logs, temporary files that can be recreated
✅ Sharing between containers - Multiple containers in the same pod need to share data
✅ Configuration delivery - Providing config files or secrets to containers
✅ Data doesn’t need persistence - Any data that can be lost when the pod restarts

Don’t use ephemeral volumes when:

❌ Data must persist - Database files, user uploads, application state
❌ Data survives restarts - Any data that must be available after pod restart
❌ Critical data - Data that cannot be regenerated or recreated

Comparison: Ephemeral vs Persistent

Best Practices

1. Use emptyDir for temporary data - Perfect for caches, temporary files, and scratch space
2. Use configMap for configuration - Keep configuration separate from container images
3. Use secret for sensitive data - Store credentials, certificates, and keys securely
4. Set size limits - Use sizeLimit for emptyDir to prevent disk space issues
5. Use memory-backed storage carefully - tmpfs is faster but limited by node memory
6. Mount secrets read-only - Always set readOnly: true for secret volumes when possible
7. Understand lifecycle - Remember that ephemeral volumes are destroyed when pods terminate

Common Patterns

Cache Pattern

apiVersion: v1
kind: Pod
metadata:
  name: app-with-cache
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: cache
      mountPath: /var/cache/nginx
  volumes:
  - name: cache
    emptyDir:
      sizeLimit: 1Gi

Multi-Container Shared Data

apiVersion: v1
kind: Pod
metadata:
  name: app-with-sidecar
spec:
  containers:
  - name: app
    image: myapp
    volumeMounts:
    - name: shared
      mountPath: /shared
  - name: sidecar
    image: logger
    volumeMounts:
    - name: shared
      mountPath: /logs
  volumes:
  - name: shared
    emptyDir: {}

Configuration from ConfigMap

apiVersion: v1
kind: Pod
metadata:
  name: app-configured
spec:
  containers:
  - name: app
    image: myapp
    volumeMounts:
    - name: config
      mountPath: /etc/app
      readOnly: true
  volumes:
  - name: config
    configMap:
      name: app-config
      defaultMode: 0644

See Also

• ConfigMaps - Creating and managing ConfigMaps
• Secrets - Creating and managing Secrets
• Persistent Volumes - Persistent storage that survives pod deletion
• CSI Persistent Volumes - Modern persistent volume interface