Use CSI drivers

The Container Storage Interface (CSI) is a specification for container orchestrators to manage block and file-based volumes for storing data. Storage vendors can each create a single CSI driver that works with multiple container orchestrators. The Kubernetes community maintains sidecar containers that a containerized CSI driver can use to interface with Kubernetes controllers in charge of managing persistent volumes, attaching volumes to nodes (if applicable), mounting volumes to pods, taking snapshots, and so on. These sidecar containers include a driver registrar, external attacher, external provisioner, and external snapshotter.

Mirantis supports version 1.0+ of the CSI specification. Therefore, MKE can manage storage back ends that ship with an associated CSI driver.


Enterprise storage vendors provide CSI drivers (Mirantis does not). Kubernetes does not enforce a specific procedure for how storage providers (SP) should bundle and distribute CSI drivers.

Review the Kubernetes CSI Developer Documentation for CSI architecture, security, and deployment details.


  1. Select a CSI driver to use with Kubernetes. See the certified CSI drivers table below.

  2. Install MKE.

  3. (Optional) Set the --storage-expt-enabled flag in the MKE install configuration to enable experimental storage features in Kubernetes 1.14. For feature details, refer to the Kubernetes documentation.

  4. Install the CSI plugin from your storage provider.

  5. Apply RBAC for sidecars and the CSI driver.

  6. Perform static or dynamic provisioning of PVs using the CSI plugin as the provisioner.

Certified CSI drivers

The following table lists the MKE certified CSI drivers.

Partner name

Kubernetes on MKE

Dell EMC

Certified (CSI)


Certified (CSI)


Certified (Trident - CSI)

CSI driver deployment

For easy deployment, storage vendors can package the CSI driver in containers. In the context of Kubernetes clusters, containerized CSI drivers typically deploy as StatefulSets for managing the cluster-wide logic and DaemonSets for managing node-specific logic.


  • You can deploy multiple CSI drivers for different storage back ends in the same cluster.

  • To avoid credential leak to user processes, Kubernetes recommends running CSI Controllers on master nodes and the CSI node plugin on worker nodes.

  • MKE allows running privileged pods, which is required to run CSI drivers.

  • The Docker daemon on the hosts must be configured with Shared Mount propagation for CSI. This allows the sharing of volumes mounted by one container into other containers in the same pod or even to other pods on the same node. By default, Docker daemon in MKE enables “Bidirectional Mount Propagation”.

For additional information, refer to the Kubernetes CSI documentation.

Role-based access control (RBAC)


Pods containing CSI plugins must have the appropriate permissions to access and manipulate Kubernetes objects.

Using YAML files that the storage vendor provide, you can configure the cluster roles and bindings for service accounts associated with CSI driver pods. MKE administrators must apply those YAML files to properly configure RBAC for the service accounts associated with CSI pods.


Dynamic provisioning

Dynamic provisioning of persistent storage depends on the capabilities of the CSI driver and underlying storage back end. The provider of the CSI driver should document the parameters available for configuration (refer to CSI HostPath Driver for a generic CSI plugin example).

Manage CSI deployment

You can access CSI deployments detail from the MKE user interface (UI). In particular:

  • Persistent storage objects

    Navigate to Kubernetes > Storage for information on such persistent storage objects as StorageClass, PersistentVolumeClaim, and PersistentVolume.

  • Volumes

    Navigate to any Pod details page in the Kubernetes > Pods section to view the Volumes information for that pod.

See also