What is a Volume in Kubernetes, and how does it differ from a Docker volume?

The problem Volumes solve

A container's own filesystem is ephemeral — anything written to it is lost the moment the container restarts, even within the same Pod (a crash and restart of a single container gets a fresh filesystem). This is fine for a purely stateless process, but breaks anything needing to persist data across a restart, or needing to share data between multiple containers in the same Pod.

The Volume abstraction: attached to the Pod, not the container

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
    - name: app
      image: myapp:1.0
      volumeMounts:
        - name: cache-volume
          mountPath: /app/cache
    - name: sidecar
      image: sidecar:1.0
      volumeMounts:
        - name: cache-volume        # same volume, mounted into a second container
          mountPath: /shared/cache
  volumes:
    - name: cache-volume
      emptyDir: {}

Because the Volume is defined at the Pod level and mounted into whichever containers declare it, both containers in this Pod see the same underlying storage — and, depending on volume type, data written to it can survive an individual container within the Pod restarting, even though the Volume's own lifetime is still ultimately tied to the Pod (an emptyDir, specifically, is deleted when the Pod itself is deleted, regardless of how many times its containers individually restarted along the way).

Many volume "types," one consistent Pod-level interface

Kubernetes Volumes aren't one storage mechanism — the volumes field supports many distinct types, each backed by different underlying storage: emptyDir (ephemeral, node-local scratch space), hostPath (a path on the node's own filesystem), configMap/secret (presenting Kubernetes objects as files — see the ConfigMap question), and persistent types backed by a PersistentVolumeClaim (network/cloud-backed storage that can outlive the Pod entirely — see that question). All of these are mounted into containers using the exact same volumeMounts syntax, regardless of what's actually backing them.

How this differs from a plain Docker volume

Docker's own volume concept is scoped to a single container/host and doesn't have a native notion of "shared across a group of co-located containers with different lifecycle rules per volume type," nor does it have a built-in abstraction spanning many different network/cloud storage backends behind one consistent interface. Kubernetes's Volume model is a broader, Pod-centric abstraction specifically designed to unify wildly different storage backends (local ephemeral scratch space, cloud block storage, network file shares, Kubernetes-object-as-file) under one API, so a Pod spec doesn't need different mounting logic depending on what's actually providing the storage underneath.

Ephemeral vs. persistent, at a glance

Understanding this table is the key to answering "will my data survive X" questions correctly — the answer depends entirely on which volume type is in play, not on some single universal Kubernetes storage guarantee.