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 the following:

  • Managing persistent volumes

  • Attaching volumes to nodes, if applicable

  • Mounting volumes to Pods

  • Taking snapshots

These sidecar containers include a driver registrar, external attacher, external provisioner, and external snapshotter.

Mirantis supports version 1.0 and later of the CSI specification, and thus MKE can manage storage backends that ship with an associated CSI driver.


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

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


  1. Select a CSI driver to use with Kubernetes from the following MKE-certified CSI drivers:

    Partner name

    Kubernetes on MKE

    Dell EMC

    Certified (CSI)


    Certified (CSI)


    Certified (Trident - CSI)

  2. Optional. Set the --storage-expt-enabled flag in the MKE install configuration to enable experimental Kubernetes storage features.

  3. Install the CSI plugin from your storage provider.

  4. Apply RBAC for sidecars and the CSI driver.

  5. Perform static or dynamic provisioning of PersistentVolumes (PVs) using the CSI plugin as the provisioner.

CSI driver deployment

The simplest way to deploy CSI drivers is for storage vendors to package them 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.

Note the following considerations:

  • You can deploy multiple CSI drivers for different storage backends 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 to other Pods on the same node. By default, MKE enables bidirectional mount propagation in the Docker daemon.

Refer to Kubernetes CSI documentation for more information.

Role-based access control (RBAC)

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

Using YAML files that the storage vendor provides, 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.


The dynamic provisioning of persistent storage depends on the capabilities of the CSI driver and of the underlying storage backend. Review the CSI driver provider documentation for the available parameters. Refer to CSI HostPath Driver for a generic CSI plugin example.

You can access the following CSI deployment information in the MKE web UI:

Persistent storage objects

In the MKE web UI left-side navigation panel, navigate to Kubernetes > Storage for information on persistent storage objects such as StorageClass, PersistentVolumeClaim, and PersistentVolume.


In the MKE web UI left-side navigation panel, navigate to Kubernetes > Pods, select a Pod, and scroll to Volumes to view the Pod volume information.