OpenShift Container Platform 4.2 introduces support for the CSI operator-framework-driven API. This CSI API manages the control plane to orchestrate and manage configuration and tear-down of data-path storage operations. Storage driver plug-in support was available in earlier Kubernetes releases, where it required volume plug-ins to be built into the core Kubernetes code base. Kubernetes version 1.14 and CSI API version 1.0 are integrated into OpenShift Container Platform 4.2.
Before the release of the CSI API support, volume plug-ins were distributed with the Kubernetes code. Known as “in-tree” storage drivers, each plug-in consisted of two parts: a data plane storage connector and an orchestration component that managed storage volumes. CSI enables container volume storage drivers to be provided from outside the Kubernetes code base (“out-of-tree” storage drivers). The benefit for storage vendors is that they can provide extended storage support without the need to distribute the drivers with Kubernetes. CSI drivers can deploy the storage plug-in (on worker nodes) and an operator that is called by the Kubernetes control plane infrastructure (on control plane nodes). The following figure shows a comparison of in-tree and out-of-tree CSI drivers:
A Kubernetes container infrastructure operates best with shared distributed storage. The container ecosystem has internal storage needs. Application pods require storage that can be used from the host worker node local disk storage or from a shared distributed storage pool. Applications might also require additional storage that is external to the cluster. The software application developer has many options from which to choose and can take guidance from industry best practices or published documents from trusted sources.
The upcoming 4.3 release of OpenShift Container Platform is expected to include Ceph-based OpenShift Container Storage 4.3, a means of providing integrated distributed storage for your container platform infrastructure using the new CSI drivers.