Storage

Kubernetes storage enables your applications to persist data beyond pod lifecycles. Unlike the default ephemeral storage that disappears when a pod restarts, persistent storage survives pod deletions, updates, and node failures. Think of it like the difference between RAM and a hard drive—ephemeral storage is temporary memory, while persistent storage is durable storage that keeps your data safe.

Storage Concepts

Kubernetes storage revolves around three core concepts:

1. Volumes

Volumes are the basic storage abstraction in Kubernetes. They provide a way for containers to access storage, whether it’s temporary (ephemeral) or persistent (survives pod deletion).

graph LR A[Pod] --> B[Volume] B --> C[Ephemeral<br/>emptyDir, configMap] B --> D[Persistent<br/>PV, CSI] style A fill:#e1f5ff style B fill:#fff4e1 style C fill:#ffe1e1 style D fill:#e8f5e9

2. PersistentVolumes (PV) and PersistentVolumeClaims (PVC)

PersistentVolumes are cluster-wide storage resources provisioned by administrators. PersistentVolumeClaims are requests for storage by users or applications. This separation allows developers to request storage without knowing the underlying storage implementation details.

graph TB A[Developer creates PVC] --> B[Kubernetes matches PVC to PV] B --> C[PV bound to PVC] C --> D[Pod uses PVC as volume] style A fill:#e1f5ff style B fill:#fff4e1 style C fill:#e8f5e9 style D fill:#f3e5f5

3. StorageClasses

StorageClasses enable dynamic provisioning—Kubernetes automatically creates PersistentVolumes when you create a PersistentVolumeClaim. Instead of administrators manually creating PVs, StorageClasses define templates that describe how to provision storage.

graph LR A[StorageClass] --> B[Defines provisioner] A --> C[Defines parameters] A --> D[Defines reclaim policy] E[PVC references StorageClass] --> F[Kubernetes creates PV automatically] style A fill:#e1f5ff style E fill:#fff4e1 style F fill:#e8f5e9

Storage Lifecycle

The complete storage lifecycle from request to deletion:

graph TD A[Create PVC] --> B{Static or Dynamic?} B -->|Static| C[Bind to existing PV] B -->|Dynamic| D[StorageClass provisions PV] D --> E[PV created] C --> F[PV bound to PVC] E --> F F --> G[Pod mounts PVC] G --> H[Application uses storage] H --> I[Pod deleted] I --> J{PVC deleted?} J -->|No| K[PV released but retained] J -->|Yes| L{Reclaim Policy} L -->|Retain| M[PV retained for manual cleanup] L -->|Delete| N[PV and storage deleted] style A fill:#e1f5ff style F fill:#e8f5e9 style H fill:#fff4e1 style M fill:#ffe1e1 style N fill:#ffe1e1

Storage Provisioning Methods

Kubernetes supports two ways to provision persistent storage:

Static Provisioning

Administrators manually create PersistentVolumes, and users create PersistentVolumeClaims that bind to these pre-created PVs. This is useful when you have specific storage requirements or need to use existing storage infrastructure.

Dynamic Provisioning

Kubernetes automatically creates PersistentVolumes when you create a PersistentVolumeClaim. The PVC references a StorageClass, which defines how to provision the storage. This is the recommended approach for most use cases because it’s simpler and more flexible.

Access Patterns

Different applications have different storage access requirements:

  • ReadWriteOnce (RWO) - One pod can read and write (typical for databases)
  • ReadOnlyMany (ROX) - Multiple pods can read (useful for config files)
  • ReadWriteMany (RWX) - Multiple pods can read and write (shared storage like NFS)

Common Use Cases

  • Databases - MySQL, PostgreSQL, MongoDB need persistent storage for data
  • Stateful applications - Applications that store user sessions, uploads, or other state
  • Log aggregation - Centralized logging systems that need to store log files
  • Content storage - Applications serving files, images, or other static content
  • Backups - Storing backup data that needs to persist across pod restarts

Best Practices

  1. Use dynamic provisioning - Prefer StorageClasses over static provisioning for simplicity
  2. Choose appropriate access modes - Match access modes to your application’s needs
  3. Set reclaim policies - Understand when storage is deleted vs retained
  4. Consider performance - Different storage backends have different performance characteristics
  5. Plan for backups - Persistent storage doesn’t automatically backup your data
  6. Monitor storage usage - Track PVC sizes and storage consumption

Topics

See Also

  • StatefulSets - Managing stateful applications with persistent storage
  • ConfigMaps - Using ConfigMaps as volume sources
  • Secrets - Using Secrets as volume sources