Understand Volumes in Kubernetes: emptyDir vs hostPath

Scenario

You are exploring how Kubernetes handles storage across two different volume types. Each volume type stores data differently—understanding where the data physically lives on the node is essential for debugging and designing reliable workloads.

A volume-explorer Pod needs to be created with both an emptyDir and a hostPath volume. Once it is running, you will locate the exact path where the emptyDir volume stores its data on the Kubernetes node filesystem.

Figure: emptyDir and hostPath volume architecture showing mount points, lifecycle, and storage locations on the Kubernetes node.

Task

1. Create a Pod named volume-explorer in the storage-lab namespace using busybox:stable, with a container named explorer that mounts both volume types and writes data to each on startup:

• emptyDir — volume name cache-vol, mounted at /cache
• hostPath — volume name node-vol, host path /tmp/k8s-node-data, mounted at /node-data

2. Use the following command so the Pod writes to both volumes on startup and stays running:

   - /bin/sh
   - -c
   - |
     echo 'cache volume data'    > /cache/cache.log &&
     echo 'hostpath volume data' > /node-data/node.log &&
     sleep 3600
   

   Copy to clipboard
3. Once the Pod is running, find the exact path on the node where the emptyDir volume (cache-vol) is stored and enter it below :

kubectl get pod volume-explorer -n storage-lab -o jsonpath='{.metadata.uid}'

Understanding the Challenge

This challenge explores the two most fundamental Kubernetes volume types. Each one answers the same question differently: Where does the data actually live?

The Two Volume Types

emptyDir is created fresh when a Pod starts and deleted when the Pod is removed. It is stored on the node's filesystem under a kubelet-managed path that includes the Pod UID. It is useful for temporary scratch space or sharing data between containers in the same Pod. There is no data after the Pod ends.

By default, emptyDir is disk-backed — it uses the node's regular filesystem (disk or SSD). Kubernetes also supports memory-backed emptyDir by setting medium: Memory, which stores data in a tmpfs mount (RAM) instead. Memory-backed emptyDir is significantly faster than disk-backed, but the data counts against the container's memory limit and is lost immediately if the node reboots — even faster than the normal emptyDir lifecycle.

# disk-backed (default) — no medium field needed
volumes:
- name: cache-vol
  emptyDir: {}

# memory-backed — uses RAM instead of disk
volumes:
- name: cache-vol
  emptyDir:
    medium: Memory
    sizeLimit: 128Mi  # optional but recommended — prevents OOM on the node

To practice configuring a memory-backed emptyDir with a size limit, see the challenge below:

hostPath maps a real directory from the worker node's filesystem into the Pod. The data lives on the node at the exact path you specify — not inside the Pod — so it survives Pod deletion as long as the Pod is recreated on the same node. If the Pod moves to a different node, it sees a different (or empty) directory. Kubernetes has no awareness of this path and does not manage or clean it up.

emptyDir vs hostPath — The key difference

Step 1 : Create the Pod with both volumes

kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: volume-explorer
  namespace: storage-lab
spec:
  containers:
  - name: explorer
    image: busybox:stable
    command:
    - /bin/sh
    - -c
    - |
      echo 'cache volume data'    > /cache/cache.log &&
      echo 'hostpath volume data' > /node-data/node.log &&
      sleep 3600
    volumeMounts:
    - name: cache-vol          # emptyDir — temporary, Pod lifetime only
      mountPath: /cache
    - name: node-vol           # hostPath — data stays on node, unmanaged
      mountPath: /node-data
  volumes:
  - name: cache-vol
    emptyDir: {}               # Kubernetes creates and manages this path

  - name: node-vol
    hostPath:
      path: /tmp/k8s-node-data # you define this path — Kubernetes does not manage it
EOF

pod/volume-explorer created

Step 2 : Wait for the Pod to be Running

kubectl get pod volume-explorer -n storage-lab

NAME               READY   STATUS    RESTARTS   AGE
volume-explorer    1/1     Running   0          15s

Step 3 : Verify data written to emptyDir (/cache)

kubectl exec volume-explorer -n storage-lab -- cat /cache/cache.log

cache volume data

Step 4 : Verify data written to hostPath (/node-data)

kubectl exec volume-explorer -n storage-lab -- cat /node-data/node.log

hostpath volume data

This file physically exists at /tmp/k8s-node-data/node.log on the worker node — a path you defined manually. Kubernetes has no knowledge of this path and will not clean it up when the Pod is deleted.

Step 5 : Find the emptyDir path on the node

Unlike hostPath where you chose the path yourself, emptyDir is stored at a path that Kubernetes constructs from the Pod's UID and the volume name. You need to look it up — it is different for every Pod.

Fetch the Pod UID and node name and note down both values — you will use them manually in the steps below:

POD_UID=$(kubectl get pod volume-explorer -n storage-lab -o jsonpath='{.metadata.uid}')
NODE=$(kubectl get pod volume-explorer -n storage-lab -o jsonpath='{.spec.nodeName}')
echo "UID : $POD_UID"
echo "Node: $NODE"

UID : cae81e54-c585-45a1-ae49-1a6b41761cbc
Node: node-01

SSH into the node and become root — /var/lib/kubelet is owned by root and requires elevated access:

ssh node-01
sudo -i

List the kubelet volumes directory for this Pod — substitute your noted UID for <pod-uid>:

ls /var/lib/kubelet/pods/<pod-uid>/volumes/

kubernetes.io~empty-dir
kubernetes.io~projected

You will see two subdirectories — not just one. Each corresponds to a different volume plugin type that Kubernetes used for this Pod:

• kubernetes.io~empty-dir — this is where your cache-vol emptyDir lives
• kubernetes.io~projected — this is automatically created by Kubernetes for every Pod, even if you did not define it yourself

kubectl exec volume-explorer -n storage-lab -- ls /var/run/secrets/kubernetes.io/serviceaccount/

ca.crt  namespace  token

ls /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~projected/

kube-api-access-b8b58

Now navigate into the emptyDir directory:

ls /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~empty-dir/

cache-vol

Navigate into cache-vol and use pwd to print the exact full path — this is the answer to the input task:

cd /var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~empty-dir/cache-vol
pwd

/var/lib/kubelet/pods/cae81e54-c585-45a1-ae49-1a6b41761cbc/volumes/kubernetes.io~empty-dir/cache-vol

That full path (with your actual Pod UID) is what you enter in the input task. The format is always:

/var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~empty-dir/cache-vol

Confirm the data is there:

cat cache.log

cache volume data

/var/lib/kubelet/pods/<pod-uid>/volumes/kubernetes.io~empty-dir/<vol-name>

/var/lib/rancher/k3s/agent/kubelet/pods/<pod-uid>/volumes/kubernetes.io~empty-dir/<vol-name>

Copy the output of pwd — with your actual Pod UID in it — and paste it as your answer in the input task.

Step 6 : Compare hostPath on the node

While still on the node, also check the hostPath location:

cat /tmp/k8s-node-data/node.log

hostpath volume data

Side by side, this confirms the difference:

• emptyDir → /var/lib/kubelet/pods/<uid>/volumes/kubernetes.io~empty-dir/cache-vol/ — path chosen by Kubernetes, unknown to you until you look it up
• hostPath → /tmp/k8s-node-data/ — path chosen by you, completely unmanaged by Kubernetes