vSphere Storage for Kubernetes, also called vSphere Cloud Provider, was introduced in 2017 and became the first vSphere storage solution for Kubernetes. The main goal of that project was to expose vSphere storage and features to Kubernetes users. The project offered an in-tree volume plug-in that has been actively used by various Kubernetes as a service solutions, such as TKGI, OpenShift, GKE On-Prem, and so on. Cloud Native Storage (CNS) is a result of evolution and productization of vSphere Storage for Kubernetes and is also enterprise ready.

The main goal of CNS is to enable vSphere and vSphere storage, including vSAN, as a platform to run stateful Kubernetes workloads. vSphere has a great data path which is highly reliable, highly performant and mature for enterprise use. CNS enables access of this data path to Kubernetes and brings an understanding of Kubernetes volume and pod abstractions to vSphere. CNS was first released in vSphere 6.7 Update 3.

CNS Architecture

CNS consists of the following components:
  • CNS in vCenter Server.
  • vSphere volume driver in Kubernetes.
Under vSphere, CNS control plane introduces a concept of volumes, such as container volumes and persistent volumes. It is the storage control plane for container volumes. CNS is responsible for managing the lifecycle of volumes, including operations such as create, read, update, and delete. It is also responsible for managing volume metadata, snapshot and restore, volume copy and clone, as well as monitoring the health and compliance of volumes. These volumes are independent of the virtual machine lifecycle and have their own identity in vSphere.

CNS leverages the existing Storage Policy Based Management (SPBM) functionality for volume provisioning. The DevOps users can use the storage policies, created by the vSphere administrator in vSphere, to specify the storage SLAs for the application volumes within Kubernetes. This way, CNS enables the DevOps users to self-provision storage for their apps with desired storage SLAs. CNS honors these storage SLAs by provisioning the volume on an SPBM policy-compliant datastore in vSphere. As a result, the SPBM policy is applied at the granularity of a container volume.

CNS supports block volumes backed by First Class Disk (FCD) and file volumes backed by vSAN file shares. A block volume can only be attached to one Kubernetes pod with ReadWriteOnce access mode at any point in time. A file volume can be attached to one or more pods with ReadWriteMany/ReadOnlyMany access modes.

In Kubernetes, CNS provides a volume driver that consist of two sub components.
  • CSI Plug-in: The CSI plug-in is responsible for volume provisioning, attaching and detaching the volume to VMs, mounting, formatting, and unmounting volumes from the pod within the node VM, and so on. It is built as an out-of-tree CSI plugin for Kubernetes.
  • Syncer: The syncer is responsible for pushing the PV, PVC, and pod metadata to CNS. It also has a CNS operator that is used in the context of vSphere with Kubernetes, formerly called Project Pacific.