Persistent Storage Basics: Using Volumes in Kubernetes

Previously in this course, we explored troubleshooting Pod crashes and managing application configuration. While those lessons taught you how to keep your applications running, we haven't yet addressed how to keep your application's data running. In this lesson, we move beyond the ephemeral nature of containers to implement basic persistence.

The Problem: Ephemeral Storage

In standard container operation, the container's filesystem is ephemeral. When you write data to a file inside a container—say, a log file or a local database—that data exists only as long as the container process is alive. If the Pod is deleted, the node reboots, or the container crashes and restarts, that data is wiped clean.

This behavior is by design; it keeps containers lightweight and stateless. However, real-world applications often need to read or write files that must persist across these lifecycle events. To solve this, Kubernetes uses Volumes.

Understanding Volumes

A Volume in Kubernetes is essentially a directory, accessible to the containers in a Pod, which is backed by a storage medium. Unlike the container's internal filesystem, the lifecycle of a Volume is tied to the Pod, not the specific container process.

Think of it this way:

• Container Filesystem: Your "scratchpad." It's fast, but everything on it is deleted when the container restarts.
• Volume: Your "hard drive." It's attached to the Pod. If the container crashes and restarts, the Volume remains, and your data is waiting for you when the container comes back up.

The hostPath Volume Type

For learning purposes, we start with the simplest form of storage: the hostPath volume. A hostPath mounts a file or directory from the host node’s filesystem directly into your Pod.

Warning: hostPath is powerful but dangerous in production. Because it exposes the node's filesystem, a compromised pod could potentially read or write sensitive host files. It is strictly for single-node development or specific system-level tasks.

Worked Example: Persisting Data

Let's create a Pod that writes a timestamp to a file inside a hostPath volume. Even if we delete and recreate the Pod, the file will remain on the host.

Create a file named persistent-pod.yaml:

YAML
apiVersion: v1
kind: Pod
metadata:
  name: data-persistence-demo
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["/bin/sh", "-c", "while true; do date >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: host-storage
      mountPath: /data
  volumes:
  - name: host-storage
    hostPath:
      path: /tmp/k8s-data # Directory on the node
      type: DirectoryOrCreate

Apply this manifest with kubectl apply -f persistent-pod.yaml. Once running, the container will append the current time to /data/out.txt every five seconds. If you delete this Pod and create a new one using the same hostPath, the new Pod will see the existing out.txt file and continue appending to it.

Hands-on Exercise

1. Verify: After running the Pod, wait 30 seconds, then check the logs: kubectl logs data-persistence-demo.
2. Delete: Delete the pod using kubectl delete pod data-persistence-demo.
3. Re-create: Apply the same manifest again.
4. Observe: Check the logs of the new pod. You will see the original data is still there, followed by the new timestamps.

Common Pitfalls

• Node Affinity: A hostPath is tied to a specific node. If your cluster has multiple nodes, your Pod might be scheduled on a different node, where the path /tmp/k8s-data doesn't exist or holds different data. This is why hostPath is rarely used in production clusters.
• Permissions: The container runs as a specific user (often root, but not always). Ensure that the directory on the host has the correct permissions so the container can actually write to it.
• Type mismatch: Always specify type: DirectoryOrCreate in your hostPath configuration; otherwise, Kubernetes will fail if the directory does not exist on the host before the Pod starts.

FAQ

Q: Is hostPath the standard way to handle storage? A: No. It is the most basic, but in production, we use Persistent Volumes (PVs) and Claims (PVCs) which allow Kubernetes to dynamically provision storage from cloud providers like AWS EBS or Google Persistent Disk.

Q: Does the data disappear if I delete the host node? A: Yes. Because hostPath is physically stored on the node, destroying the node destroys the data.

Recap

We’ve learned that standard container storage is ephemeral and that Volumes bridge the gap to persistence. You now know how to define a hostPath volume to mount host directories into your Pods, ensuring your data survives container restarts.

Up next: We will look at the ReplicaSet Controller, which introduces the ability to ensure a specific number of Pods are always running, even if a node fails.