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 can be used by a containerized CSI driver to interface with Kubernetes controllers in charge of managing persistent volumes, attaching volumes to nodes (if applicable), mounting volumes to pods, taking snapshots, and more. These sidecar containers include a driver registrar, external attacher, external provisioner, and external snapshotter.
Docker Enterprise 3.0 supports version 1.0+ of the CSI specification. Therefore, MKE 3.2 (as part of Docker Enterprise 3.0) can manage storage backends that ship with an associated CSI driver, as illustrated in the following diagram.
Note
Docker Enterprise does not provide CSI drivers. CSI drivers are provided by enterprise storage vendors. 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.
--storage-expt-enabled
flag in the MKE install
configuration if you want to enable experimental storage features in
Kubernetes 1.14. For details on these features, refer to the Kubernetes
documentation.The following table lists the MKE certified CSI drivers.
Partner name | Kubernetes on Docker Enterprise 3.0 |
---|---|
NetApp | Certified (Trident - CSI) |
EMC/Dell | Certified (VxFlexOS CSI driver) |
VMware | Certified (CSI) |
Portworx | Certified (CSI) |
Nexenta | Certified (CSI) |
Blockbridge | Certified (CSI) |
Storidge | Certified (CSI) |
Refer to documentation from your storage vendor around how to deploy the
desired CSI driver. For easy deployment, storage vendors can package the
CSI driver in containers. In the context of Kubernetes clusters,
containerized CSI drivers are typically deployed as StatefulSets
for
managing the cluster-wide logic and DaemonSets
for managing
node-specific logic.
You can deploy multiple CSI drivers for different storage backends in the same cluster.
Note
For additional information, refer to the Kubernetes CSI documentation.
Pods containing CSI plugins need the appropriate permissions to access and manipulate Kubernetes objects. The desired cluster roles and bindings for service accounts associated with CSI driver pods can be configured through YAML files distributed by the storage vendor. MKE administrators must apply those YAML files to properly configure RBAC for the service accounts associated with CSI pods.
Dynamic provisioning of persistent storage depends on the capabilities of the CSI driver and underlying storage backend. The provider of the CSI driver should document the parameters available for configuration. Refer to CSI HostPath Driver for a generic CSI plugin example.
CSI deployments detail is available 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.