Storage
Mobility
Protection
Analysis and control
TOPICShare
What is Red Hat OpenShift Container Storage (OpenShift Data Foundation)?
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:
- Integrated management—provides greater control and efficiency for storage provisioning.
- Seamless persistent storage—enables dynamic provisioning of persistent volumes for applications and services, within the native OpenShift interface.
- Rapid deployment—offers operator-based deployments of OpenShift Container Storage on clusters.
In this article, you will learn:
- OpenShift Persistent Storage
- OpenShift Ephemeral Storage
- Under the Hood: How OpenShift Uses the Container Storage Interface (CSI)
- OpenShift Container Storage with Cloud Volumes ONTAP
OpenShift Persistent Storage
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.
Persistent Volume Lifecycle in OpenShift Container Platform
In OpenShift Container Platform, Persistent Volumes go through the following lifecycle stages:
- Administrators provision storage—the administrator either configures a dynamic provisioner that creates PVs in response to claims, or sets up PVs manually, knowing the required capacity in advance.
- Binding PV to a claim—developers issue PVCs, in which they request the type and capacity of storage they need. The main node watches for PVCs, and when a PVC meets the criteria, it binds the claim to the volume (or, if there is no appropriate volume and a provisioner is set up, creates a new PV).
- Pods access volumes—after binding occurs, the claim becomes available to the pod as a persistent volume, for as long as needed by the pod. The pod can access a volume by adding a persistentVolumeClaim statement in its YAML configuration.
OpenShift Ephemeral Storage
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:
- Root ephemeral storage—a partition on the node that houses the kubelet root directory and the /var/log/ It is shared by pods, the operating system, and daemons.
- Runtime ephemeral storage—this partition can optionally be added. It is optimized for storing container layers and has isolation that can prevent each container from accessing layers belonging to another container.
Related content: read our guide to OpenShift Architecture
Under the Hood: How OpenShift Uses the Container Storage Interface (CSI)
The CSI enables OpenShift Container Platform to consume information from storage backend sources.
CSI Architecture
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.
Image Source: OpenShift
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:
- Attacher container—an external CSI container translates detach and attach calls from OpenShift’s container platform to respective ControllerUnpublish and ControllerPublish calls to a CSI driver.
- Provisioner container—an external CSI container that can translate delete and provision calls from OpenShift’s container platform to respective DeleteVolume and CreateVolume calls to CSI drivers.
- CSI driver container—communicates with the attacher and provisioner containers using UNIX domain sockets and passes requests directly to storage components.
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:
- A CSI driver registrar—registers a CSI driver into an openshift-node service that runs on a node.
- A CSI driver—directly connects to the openshift-node process via an available UNIX domain socket.
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.
OpenShift Container Storage with Cloud Volumes ONTAP
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.
