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

  1. 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.
  2. When a pod is using a PVC it's retained for the pod's lifetime.
  3. Reclaim takes place at PVC deletion, and can either Delete or Retain (specified in persistentVolumeReclaimPolicy).

Static provisioning

  1. Create PersistentVolume.
  2. Create PersistentVolumeClaim.
  3. Define Volume inside of Pod specification.

Dynamic provisioning

  1. Create StorageClass.
  2. Create PersistentVolumeClaim.
  3. Define Volume inside of Pod specification. The PersistentVolume is created here.

Children
  1. StorageClass
  2. Volumes

Backlinks