Container Storage Interface (CSI)

While Kubernetes was originally designed for stateless applications, the demand for statefulness led to the introduction of the Container Storage Interface (CSI).

CSI is meant to abstract how containers interact with various storage systems. Before CSI, various storage vendors needed to develop their own drivers and bake them into K8s source code which meant that the latest features for a storage solution would be coupled to a K8s release containing those latest changes.

With the emergance of CSI; which is an API specification, drivers implementing the CSI specs can be used in orchestrators like K8s.

On the cluster, the CSI has the controller on the control plane and the node plugin on each node. The controller; which can be deployed as a Deployment or a StatefulSet, handles managing storage resources such as volume creation, deletion, snapshots, etc. And the node plugin; which is deployed as a DaemonSet, handles node-level operations like mounting/unmounting volumes on specific nodes.

More about volumes

At DC, we have the ONTAP-NAS StorageClass installed by the cluster admin. This is a storage solution from NetApp Trident which provides storage for apps hosted on the cluster in the form of shared file storage via NFS or SMB protocols.

The different storage access modes we've seen include:

• ReadWriteOnce (RWO) - read-write by a single node
• ReadWriteMany (RWX) - read-write by multiple nodes simultaneously

Volumes are usually defined in a Deployment template and are mounted into containers. A volume can point to a configMap resource or can hold application source code, it can also point to secret resources. Another volume type is hostPath which points at the node's filesystem making the pod dependent on the node it lives on. If the volume does not point to persistent storage, data on it is ephemeral. An example of an ephemeral volume type is emptyDir.

A PersistentVolumeClaim (PVC) is a storage request that specifies what the workload or app needs for eg. size, access mode and storage class. It references a StorageClass that determines which storage backend to use. This request is evaluated by the control plane against available PVs and if suitable, the claim is bound.

The image below describes a simple storage provisioning process.

At DC, PVs are provided dynamically i.e. they are created on-demand when a PVC is submitted.

In terms of backups, there exists some Custom Resource Definitions (CRDs) that can be used (see below). The snapshot controller watches these resources and triggers creating or deleting a snapshot against a CSI endpoint.

• VolumeSnapshotClass defines parameters such as the CSI driver used plus additional settings.
• VolumeSnapshot - this represents the request for a snapshot from a PVC and it maintains the status of creating the snapshot from the data held by the PVC onto the VolumeSnapshotContent.
• VolumeSnapshotContent - is the resource that represents a snapshot taken from a volume in the cluster.