Storage
Pod filesystems are writeable by default, but they'e ephemeral: the data is lost at the time the pod is terminated. Stateful applications therefore need a means of reusing volumes defined independently of the pod.
Storage in Kubernetes is split across a number of objects as it decouples the notion of a disk or share, its performance and availability targets and its consumers.
- Volumes are references to persistent storage that forms part of a pod. The lifetime of a Volume is tied to that of the Pod it's attached to, though whether or not the data lost upon termination of the Pod depends on the volume.
- PersistentVolumes represent storage devices. Unlike Volumes they're cluster-wide (though
nodeAffinity
can be used to tie them to a specific subset of the cluster). These are usually prepared in advance by administrators or created by an operator based on a StorageClass. - PersistentVolumeClaims are requests for PersistentVolumes, decoupling the implementation of the storage unit from the pod specification.
- StorageClasses declare templates for PersistentVolumes and can be used to enable dynamic provisioning based on a performance, reliability or scalability target.
Storage lifecycle
- Binding maps a PVC to a PV for use by a pod. At PVC creation time, a control loop attempts to match a PVC to a suitable PV. Pods will remain in pending state until a matching PV can be found, allowing provisioners (or administrators) to prepare the storage.
- When a pod is using a PVC it's retained for the pod's lifetime.
- Reclaim takes place at PVC deletion, and can either
Delete
orRetain
(specified inpersistentVolumeReclaimPolicy
).
Static provisioning
- Create PersistentVolume.
- Create PersistentVolumeClaim.
- Define Volume inside of Pod specification.
Dynamic provisioning
- Create StorageClass.
- Create PersistentVolumeClaim.
- Define Volume inside of Pod specification. The PersistentVolume is created here.
Children
Backlinks