Full lesson
Explore the full explanation, examples, and visuals at your own pace.
Keep durable data outside the Pod, on persistent storage.
Keep durable data outside the Pod, on persistent storage. A Volume, claim, and PersistentVolume connect a Pod to storage.
A Volume gives the Pod a mount
The App Pod mounts a Volume, which gives the application a place to read and write files. But a mount describes how the Pod accesses storage, not how long the data lasts; some Volume types are temporary and disappear with the Pod.
The Volume names a claim
The App Pod mounts a Volume, and that Volume uses the app-data PVC. The Pod names the storage request it needs, not a particular disk. That keeps the Pod configuration separate from the choice of backing storage.
The claim binds to persistent storage
The app-data PVC doesn't hold the file itself. It binds to a PersistentVolume, which represents the underlying storage resource. The Pod's Volume uses that claim, so the app reads and writes through the mount, while the data lives in the backing storage.
If the app Pod is deleted, which part should still represent its backing storage?
Let's think this through. If the app Pod is deleted, which part should still represent its backing storage? A: The old Pod. B: The PersistentVolume. C: The Pod's temporary Volume. Choose an answer, or just think it through. I'll explain in a moment.
- The old Pod
- The PersistentVolume
- The Pod's temporary Volume
If the app Pod is deleted, which part should still represent its backing storage?
The answer is B: The PersistentVolume. The PersistentVolume represents storage with a lifecycle separate from that Pod. A Volume is how a Pod mounts storage; a temporary Volume would not preserve this data.
- The old Pod
- The PersistentVolume
- The Pod's temporary Volume
The app writes a file on Node A
The App Pod on Node A writes through its mounted Volume. That mount connects to the app-data PVC, which binds to the PV, and the PV is backed by Storage outside Node A. The file is stored beyond the Pod’s own lifetime.
A replacement Pod mounts the same claim
The Pod moves; its data doesn’t have to. On Node B, the replacement App Pod mounts the same app-data PVC, which remains bound to the PV backed by Storage. Once that mount succeeds, the Pod can read the file written before deletion.
Persistence has conditions
A temporary Volume loses data with its Pod. A claimed PersistentVolume can preserve it, but the replacement on Node B can read it only if the backend is reachable there and its access rules allow the mount.
- Temporary Volumes lose Pod-scoped data
- Storage must be usable from Node B
- Access rules must permit the mount
New Pod, same backing storage
A Volume is a Pod's storage mount; a claim requests persistent storage; a PersistentVolume represents the backing resource. The replacement Pod can read existing data only if that storage supports its mount.