Skip to main content
In this lesson we introduce how storage works for containers and why Docker storage fundamentals matter when you move to Kubernetes. Kubernetes builds on container storage concepts, so understanding Docker’s storage drivers and volume plugins makes the transition to Kubernetes storage much clearer. Why this matters
  • Containers are ephemeral by design: a container filesystem can disappear when the container is removed.
  • Persistent data requires mechanisms that outlive the container lifecycle — this is where Docker volumes and external storage plugins come in.
  • Kubernetes leverages similar principles (PersistentVolumes, CSI drivers), so the mental model you build here transfers directly.
Core Docker storage concepts
  • Storage drivers
    • These are part of the Docker engine and implement how image layers are combined and how the container writable layer is managed (the union filesystem).
    • Examples: overlay2, aufs, devicemapper.
    • Impact: choice of storage driver affects performance, disk usage, copy-on-write semantics, and portability across hosts.
  • Volume driver plugins
    • Provide persistent storage independent of a container’s lifecycle.
    • Include the built-in local driver and third-party plugins that integrate external storage systems (NFS, cloud block storage, etc.).
    • Use case: share data between containers, preserve state across restarts, or mount remote storage into containers.
Quick comparison How to inspect basic Docker storage details
  • Check the active storage driver:
  • List Docker volumes:
  • Create a simple local volume:
Storage driver deep-dive (high-level)
  • Union filesystems (e.g., overlay2, aufs) merge image layers with a writable upper layer for containers. They are typically fast and space-efficient.
  • Block-device-backed drivers (e.g., devicemapper when used in direct-lvm mode) provide different performance and isolation characteristics and may introduce more complex setup/maintenance requirements.
  • Considerations: kernel support, host OS, kernel versions, backing filesystem, and workload I/O patterns all influence the best driver choice.
Volume driver plugins and persistent storage
  • The built-in local driver is simple, mounts host directories or creates volumes on the host filesystem.
  • Third-party plugins (NFS, cloud-provided block/FS drivers) allow containers to use networked or cloud-backed storage that persists beyond container and host lifecycles.
  • For distributed or stateful workloads, use networked or cloud-backed storage that supports the access and durability guarantees your application requires.
Implications for Kubernetes storage
  • Kubernetes separates the concerns introduced here:
    • Storage drivers = how container images/filesystems work on nodes (node-level detail).
    • Kubernetes introduces PersistentVolumes (PV) and PersistentVolumeClaims (PVC) and relies on CSI (Container Storage Interface) drivers for in-cluster, pluggable storage.
  • Understanding Docker storage helps when debugging node-level storage issues, selecting underlying block/FS types for PVs, and choosing or configuring CSI drivers.
The image is a simple slide titled "Docker Storage" showing two rounded rectangles labeled "Storage Drivers" and "Volume Drivers." It has a dark blue background and minimalist design.
If you’ve already covered Docker storage in the Docker Training Course for the Absolute Beginner, you can skip this lesson. Otherwise, continuing will be a helpful refresher before diving into Kubernetes storage concepts.
Links and references

Watch Video