Red Hat OpenShift Container Storage (now called Red Hat OpenShift Data Foundation) is a software-defined persistent storage solution, designed especially for OpenShift Container Platform.
OpenShift Data Foundation offers highly available, dynamic, and stateful container-native storage. It lets you perform on-demand provisioning and de-provisioning of storage directly from the OpenShift administrator console. It provides complete support for persistent and ephemeral storage for OpenShift, with full data portability for hybrid and multicloud environments.
Key benefits include:
In this article, you will learn:
In containerized applications, managing persistent storage is a challenge. Containers or pods can shut down at any time and their local storage is lost. This is why Kubernetes makes it possible to define persistent volumes (PV) and attach them to pods, to facilitate persistent storage that outlines the lifecycle of a pod.
OpenShift Container Platform uses PVs to provide persistent storage facilities in clusters. PVs can be shared across the entire OpenShift platform.
OpenShift uses the Kubernetes persistent volume claims (PVC) mechanism to allow developers to request storage resources, without being aware of the specifics of the underlying storage equipment. PVCs are limited to specific projects, but they can access persistent volumes from anywhere in the OpenShift platform.
The OpenShift Container Platform supports many popular PV plugins including Amazon EBS, Azure Files, Azure Managed Disks, Google Cloud Persistent Disk, Cinder, iSCSI, Local Volume, NFS, and VMware vSphere.
In OpenShift Container Platform, Persistent Volumes go through the following lifecycle stages:
While persistent storage is critical for stateful containerized applications, both stateful and stateless applications need ephemeral storage. Ephemeral storage is temporary storage on the nodes that host pods and containers, and is necessary for runtime data operations, caching, and temporary storage of logs. It is shared by all pods running on a Kubernetes node.
The OpenShift Container Platform provides an ephemeral storage framework that lets each pod specify and receive the local storage it needs. It also makes it possible to schedule pods while taking into account if the target nodes meet their ephemeral storage requirements. This makes it easier to manage local storage, but keep in mind there are no guarantees of throughput and latency.
OpenShift ephemeral storage management can solve several common problems in Kubernetes deployments. It ensures pods are aware of the available storage on their nodes, guarantees that enough local storage is available for pods running on a node, and prevents pod eviction due to storage issues.
OpenShift offers two types of ephemeral storage:
Related content: read our guide to OpenShift Architecture
The CSI enables OpenShift Container Platform to consume information from storage backend sources.
A CSI driver is usually shipped as a container image, which is not aware it is running on the OpenShift Container Platform.
To use CSI storage backends, the cluster administrator deploys multiple components, which serve as a bridge connecting between a storage driver and the OpenShift Container Platform.
Here is a diagram that shows the main components running inside OpenShift pods.
The platform lets you run several CSI drivers for different backends of storage. In this case, each driver is required to have its own external controllers and a DaemonSet managed by the CSI registrar.
External CSI controllers
This type of controller can deploy one or multiple pods including the following types of containers:
CSI driver DaemonSet
This DaemonSet is responsible for running a CSI driver-installed pod on each node. It lets OpenShift’s container platform mount the node with storage provided by a CSI driver. Then, the platform can use it as persistent volumes (PVs) for pods (user workloads). A pod with a CSI driver uses the following container types:
Dynamic provisioning
To enable dynamic provisioning for persistent storage, the platform uses CSI drivers to connect to storage backends. A CSI driver provider specifies the process of creating a storage class, as well as the available configuration parameters. Storage classes enable dynamic provisioning—developers can specify a storage class in their PVC (for example, high performance storage) and receive a persistent volume belonging to that storage class.
NetApp Cloud Volumes ONTAP, the leading enterprise-grade storage management solution, delivers secure, proven storage management services on AWS, Azure and Google Cloud. Cloud Volumes ONTAP capacity can scale into the petabytes, and it supports various use cases such as file services, databases, DevOps or any other enterprise workload, with a strong set of features including high availability, data protection, storage efficiencies, Kubernetes integration, and more.
In particular, Cloud Volumes ONTAP supports Kubernetes Persistent Volume provisioning and management requirements of containerized workloads.
Learn more about Dynamic Kubernetes Persistent Volume Allocation with NetApp Trident CSI and Cloud Volumes ONTAP, and learn more about how Cloud Volumes ONTAP helps to address the challenges of containerized applications in these Kubernetes Workloads with Cloud Volumes ONTAP Case Studies.