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).
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.
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.
Storage Lifecycle
The complete storage lifecycle from request to deletion:
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
- Use dynamic provisioning - Prefer StorageClasses over static provisioning for simplicity
- Choose appropriate access modes - Match access modes to your application’s needs
- Set reclaim policies - Understand when storage is deleted vs retained
- Consider performance - Different storage backends have different performance characteristics
- Plan for backups - Persistent storage doesn’t automatically backup your data
- Monitor storage usage - Track PVC sizes and storage consumption
Topics
- Volume Types - Different types of volumes available in Kubernetes
- Access Modes & Reclaim Policy - How volumes are accessed and managed
- StorageClasses - Dynamic provisioning and storage templates
- PVs & PVCs - Persistent Volumes and Persistent Volume Claims
- Snapshots & Cloning - Volume snapshots and cloning
- Storage Integration - Integrating with existing storage systems
- Backup & Restore - Data backup and restore strategies
- Cloud Volumes - Cloud provider storage integration
See Also
- StatefulSets - Managing stateful applications with persistent storage
- ConfigMaps - Using ConfigMaps as volume sources
- Secrets - Using Secrets as volume sources