6 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 and 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.

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.

You can install CSI plugins into a Kubernetes cluster in Oracle Cloud Native Environment. To make it easier to perform the CSI plugin installation, Oracle provides several storage related modules.

The Oracle Cloud Infrastructure Cloud Controller Manager module for Oracle Cloud Native Environment can be used to set up the CSI plugin for Oracle Cloud Infrastructure.

The Rook module for Oracle Cloud Native Environment can be used to set up the CSI plugin for Ceph.