1. Kubernetes for Release 2
  2. Kubernetes Architecture
  3. Storage

Storage

Every meaningful workload in the computing industry requires some sort of data storage. Persistent storage is essential when working with stateful applications such as databases, as it's important that you can retain data beyond the lifecycle of the container, or even of the pod itself.

Persistent storage in Kubernetes is handled in the form of PersistentVolume objects which are bound to pods using a PersistentVolumeClaim. You can host a PersistentVolume locally or on networked storage devices or services.

A typical Kubernetes environment involves many hosts and includes some type of networked storage. Using networked storage helps to ensure resilience and lets you take full advantage of a clustered environment. In the case where the node where a pod is running fails, a new pod can be started on another node and storage access can be resumed. This is important for database environments where replica setup has been configured.

Cloud Native Storage

Several storage projects are associated with the CNCF foundation, and the providers are included by default in Kubernetes. Storage integration is provided using plugins, referred to as the Container Storage Interface (CSI). The plugins adhere to a standard specification.

Persistent Storage

Persistent storage is provided in Kubernetes using the PersistentVolume subsystem. To configure persistent storage, you must be familiar with the following terms:

  • PersistentVolume

    A PersistentVolume defines the type of storage that's being used and the method used to connect to it. This is the real disk or networked storage service that's used to store data.

  • PersistentVolumeClaim

    A PersistentVolumeClaim defines the parameters that a consumer, such as a pod, uses to bind the PersistentVolume. The claim might specify quota and access modes to be applied to the resource for a consumer. A pod can use a PersistentVolumeClaim to gain access to the volume and mount it.

  • StorageClass

    A StorageClass is an object that specifies a volume plugin, known as a provisioner, that lets users to define PersistentVolumeClaims without needing to preconfigure the storage for a PersistentVolume. This can be used to provide access to similar volume types as a pooled resource that can be dynamically provisioned for the lifecycle of a PersistentVolumeClaim.

PersistentVolumes can be provisioned either statically or dynamically.

Static PersistentVolumes are manually created and contain the details required to access real storage and can be consumed directly by any pod that has an associated PersistentVolumeClaim.

Dynamic PersistentVolumes can be automatically generated if a PersistentVolumeClaim doesn't match an existing static PersistentVolume and an existing StorageClass is requested in the claim. A StorageClass can be defined to host a pool of storage that can be accessed dynamically. Creating a StorageClass is an optional step that's only required if you intend to use dynamic provisioning.

The process to provision persistent storage is as follows:

  1. Create a PersistentVolume or StorageClass.

  2. Create PersistentVolumeClaims.

  3. Configure a pod to use the PersistentVolumeClaim.

The process for adding and configuring NFS and iSCSI volumes is described in detail in the upstream documentation.

Container Storage Interface Plugins

The Container Storage Interface (CSI) is an Open Container Initiative standard for controlling storage workloads from container engines. Kubernetes implements this interface to provide automated control for storage workloads inside Kubernetes clusters. For a list of the Kubernetes storage provisioners, see the upstream documentation.