Free lesson · CKA Prep Program · Module 5: Storage
Attach the Right Volume Type
Volumes answer one question: where does this data live when the container restarts. This lesson maps the common types to their lifetimes so the choice becomes reflex.
10 min reading
Objectives
- Separate ephemeral from persistent volume needs in one sentence each
- Pick emptyDir, hostPath, ConfigMap/Secret or CSI for the case at hand
- Explain where the data lives when the pod dies for each type
- Mount the same volume read-only into a sidecar for inspection
Why this matters
Containers are born without memory of yesterday: every restart wipes the writable layer. Volumes attach external lifetimes to pods, and the wrong lifetime either loses data that mattered or preserves data that should never have persisted (credentials in emptyDir snapshots, secrets on hostPath). The exam tests the mapping directly.
Concepts
emptyDir lives and dies with the pod: perfect for scratch space, caches and sidecar exchange, gone on pod deletion. hostPath reaches into node files: occasionally needed for system agents, dangerous for apps because data sticks to one node and pods become unmovable. ConfigMap plus Secret volumes project cluster objects as files: configuration, never large data, with automatic updates on a delay. PersistentVolumeClaim volumes survive pods entirely and are covered in the next lessons; use them for anything that must outlive the pod.
Read-only mounts (readOnly: true) enforce intent: config consumers cannot corrupt shared data, and inspectors cannot alter evidence. SubPath mounts single files from a volume when the whole directory would shadow existing content, which is how one config file lands inside an image that already owns its directory.
Worked example
Cache plus config plus inspection, each with the right lifetime:
volumes:
- { name: cache, emptyDir: { sizeLimit: 500Mi } }
- name: app-config
configMap: { name: shop-config }
containers:
- name: app
volumeMounts:
- { name: cache, mountPath: /cache }
- { name: app-config, mountPath: /etc/shop, readOnly: true }
- name: inspector
image: busybox
command: ["sh", "-c", "ls -R /view && sleep 3600"]
volumeMounts:
- { name: cache, mountPath: /view, readOnly: true }Delete the pod and the cache evaporates while the ConfigMap persists: that asymmetry is the lesson. The inspector sees but cannot touch, which is the read-only point.
Exam notes
hostPath with anything sensitive is an anti-pattern questions love to punish: node access equals data access. ConfigMap updates propagate to mounted volumes eventually (kubelet sync period), never instantly: do not test immediacy. And sizeLimit on emptyDir triggers eviction past the cap instead of silent growth.
Quick check
A 4-question self-check. Your answers stay on your device, are never stored or sent. Only a passing score (for example 3 of 4) is saved, and only to unlock lesson progress: at least 3 correct is required before a lesson counts as complete. It never counts toward any certification assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
For three fictional needs (upload scratch space, node GPU inventory file, database credentials) name the volume type with a one-line lifetime justification each. Then mount one of them read-only into a second container and state what breaks if the mount were writable.
Pass criteria
All three types correct with lifetime reasoning; read-only mount shown; the writable-breakage answer names a concrete corruption or leak path.