Introduction

Note: This chapter describes storage products that use CSI drivers. Dell Technologies expects to release these drivers in the near future and will provide guidance with the release for using CSI-based storage products to build an enterprise-grade container ecosystem platform solution. At the time the laboratory work on this solution was completed, CSI drivers to support Dell Technologies storage products were not available. It is not possible to build a container ecosystem without container storage, and, therefore, we completed our laboratory work using Dell EMC Unity XT380-based generic NFS and generic iSCSI. The Dell EMC Ready Stack Deployment Guide for Red Hat OpenShift 4.3 reflects that choice. At the time this document was written, the Red Hat release for OpenShift Container Storage support for an OpenShift Container Platform 4.3 bare-metal deployment is still pending, and, therefore, Cluster Hardware Design also does not include requirements for cluster nodes for storage.

Stateful applications create a demand for persistent storage. All storage within OpenShift Container Platform 4.3 is managed separately from compute (worker node) resources and from all networking and connectivity infrastructure facilities. The CSI API is designed to abstract storage use and enable storage portability.

The following Kubernetes storage concepts apply to this solution:

• Persistent volume (PV)—The physical LUN or file share on the storage array. PVs are internal objects against which PVCs are created. PVs are unrelated to pods and pod storage life cycles.
• Persistent volume claim (PVC)—An entitlement that is created by the user for the specific PV.
• Storage class—A logical construct defining storage allocation for a given group of users.
• CSI driver—The software that orchestrates persistent volume provisioning and de-provisioning on the storage array. 

These resources are logical constructs that are used within the Kubernetes container infrastructure to maintain storage for all the components of the container ecosystem that depend on storage. Developers and operators can deploy applications and provision or de-provision persistent storage without having any specific technical knowledge of the underlying storage technology.

The OpenShift Container Platform administrator is responsible for provisioning storage classes and making them available to the cluster’s tenants.

Storage using PVCs is consumed or used in two ways: statically or dynamically. Static storage can be attached to one or more pods by static assignment of a PV to a PVC and then to a specific pod or pods.

Static storage provisioning

Static persistent storage provisioning involves an administrator pre-provisioning PVs to be used by Kubernetes tenants. When a user makes a persistent storage request by creating a PVC, Kubernetes finds the closest matching available PV. Static provisioning is not the most efficient method for using storage, but it might be preferred when it is necessary to restrict users from PV provisioning.

The following figure illustrates the static storage provisioning workflow in this solution:

Figure 5.         Static storage provisioning workflow

Dynamic persistent storage provisioning

Dynamic persistent storage provisioning, the most flexible provisioning method, enables Kubernetes users to secure PV provisioning on demand. Dynamic provisioning has fully automated LUN export provisioning.

The following figure shows the dynamic storage provisioning workflow in this solution:

Figure 6.         Dynamic storage provisioning workflow and benefits

After a PV is bound to a PVC, that PV cannot be bound to another PVC. This restriction effectively binds the PV to a single namespace, that of the binding project. A PV that has been created for dynamic use is a storage class object that functions as, and is automatically consumed as, a cluster resource.

PV types

OpenShift Container Platform natively supports the following PV types:

• AWS Elastic Block Store (EBS)
• Azure Disk
• Azure File
• Cinder
• Fibre Channel (FC) (can only be assigned and attached to a node)
• GCE Persistent Disk
• HostPath (local disk)
• iSCSI (generic)
• Local volume
• NFS (generic)
• Red Hat OpenShift Container Storage
• VMware vSphere

The CSI API extends the storage types that can be used within an OpenShift Container Platform solution.

PV capacity

Each PV has a predetermined storage capacity that is set in its capacity definition parameter. The storage capacity can be set or requested by a pod that is launched within the container platform. Expect the choice of control parameters to expand as the CSI API is extended and as it matures.

PV access modes

A resource provider can determine how the PV is created and can set the storage control parameters. Access mode support is specific to the type of storage volume that is provisioned as a PV. Provider capabilities determine the PV’s access modes, while the capabilities of each PV determine the modes that are supported by that volume. For example, NFS can support multiple read-write clients, but a specific NFS PV might be configured as read-only.

Pod claims are matched to volumes with compatible access modes based on two matching criteria: access modes and size. A pod claim’s access modes represent a request.

Important: At the time the laboratory work on this solution was completed, CSI drivers to support Dell Technologies storage products were not available. It is not possible to build a container ecosystem without container storage, and, therefore, we completed our laboratory work using Dell EMC Unity XT380-based generic NFS and generic iSCSI. The Dell EMC Ready Stack Deployment Guide for Red Hat OpenShift 4.3 reflects that choice. At the time of writing, the Red Hat release with OpenShift Container Storage support for an OpenShift Container Platform 4.3 bare-metal deployment is still pending, and, therefore, Cluster Hardware Design also does not include requirements for cluster nodes for storage.