OpenShift
StorageOS V2 supports Openshift v4.
OpenShift and StorageOS communicate with each other to perform actions such as creation, deletion and mounting of volumes through CSI. The CSI container running in the StorageOS Daemonset creates a Linux socket that allows the communication between OpenShift and StorageOS
Installation
StorageOS v2 supports OpenShift 4.0, 4.1, 4.2, 4.3, 4.4 and 4.5.
To install StorageOS on OpenShift, please follow our installation instructions page.
N.B. Openshift 4 uses the CRI-O container runtime that sets a default PID limit of 1024. StorageOS recommends that the limit be raised to 32768. Please see our prerequisites for more details.
OpenShift Upgrades
OpenShift provides an upgrade operator that automates the process of orchestrator version changes.
This procedure can cause StorageOS to malfunction due to sequential node restarts not taking the presence of stateful application data into consideration. To avoid this issue, make sure all stateful workloads using StorageOS Volumes are stopped - usually by scaling StatefulSets to 0. Please contact StorageOS support for further advice if required.
OpenShift requires the internal registry to be available during the upgrade, however StorageOS volumes may not be available. Therefore using StorageOS for the internal registry is not recommended.
CSI (Container Storage Interface) Note
CSI is the standard that enables storage drivers to release on their own schedule. This allows storage vendors to upgrade, update, and enhance their drivers without the need to update Kubernetes source code, or follow Kubernetes release cycles. StorageOS v2 uses CSI to implement communication with the OpenShift controlplane.
StorageOS PersistentVolumeClaims
The user can provide standard PVC definitions and StorageOS will dynamically provision them. StorageOS presents volumes to containers with standard POSIX mount targets. This enables the Kubelet to mount StorageOS volumes using standard linux device files. Checkout device presentation for more details.