vSphere with Tanzu uses several components to integrate with vSphere storage.
Cloud Native Storage (CNS) on vCenter ServerThe CNS component resides in vCenter Server. It is an extension of vCenter Server management that implements provisioning and lifecycle operations for persistent volumes. When provisioning container volumes, the component interacts with the vSphere First Class Disk functionality to create virtual disks that back the volumes. In addition, the CNS server component communicates with the Storage Policy Based Management to guarantee a required level of service to the disks. The CNS also performs query operations that allow vSphere administrators to manage and monitor persistent volumes and their backing storage objects through vCenter Server.First Class Disk (FCD) is Also called Improved Virtual Disk. It is a named virtual disk unassociated with a VM. These disks reside on a VMFS, NFS, or vSAN datastore and back ReadWriteOnce persistent volumes.
The FCD technology performs lifecycle operations related to persistent volumes outside of a lifecycle of a VM or pod.
When you use FCDs, keep in mind the following:
- FCDs do not support NFS 4.x protocols. Instead, use NFS 3.
- vCenter Server does not serialize operations on the same FCD. As a result, applications cannot simultaneously perform operations on the same FCD. Performing such operations as clone, relocate, delete, retrieve, and so on simultaneously from different threads causes unpredictable results. To avoid problems, applications must perform operations on the same FCD in a sequential order.
- FCD is not a managed object and does not support a global lock protecting multiple writes to a single FCD. As a result, FCD doesn’t support multiple vCenter Server instances managing the same FCD. If you need to use multiple vCenter Server instances with FCDs, you have the following options:
- Multiple vCenter Server instances can manage different data stores.
- Multiple vCenter Server instances do not operate on the same FCD.
Storage Policy Based ManagementStorage Policy-Based Management is a vCenter Server service that supports the provisioning of persistent volumes and their backing virtual disks according to storage requirements described in a storage policy. After provisioning, the service monitors compliance of the volume with the storage policy characteristics. For more information about Storage Policy Based Management, see Storage Policy Based Management.vSphere CNS-CSIThe vSphere CNS-CSI component conforms to Container Storage Interface (CSI) specification, an industry standard designed to provide an interface that container orchestrators like Kubernetes use to provision persistent storage. The CNS-CSI driver runs in the Supervisor Cluster and connects vSphere storage to the Kubernetes environment on a vSphere Namespace. The vSphere CNS-CSI communicates directly with the CNS control plane for all storage provisioning requests that come from vSphere Pods and pods that runs in a Tanzu Kubernetes cluster on the namespace. Paravirtual CSI (pvCSI)The pvCSI is the version of the vSphere CNS-CSI driver modified for Tanzu Kubernetes clusters. The pvCSI resides in the Tanzu Kubernetes cluster and is responsible for all storage-related requests originating from the Tanzu Kubernetes cluster. The requests are delivered to the CNS-CSI, which then propagates them to CNS in vCenter Server. As a result, the pvCSI does not have direct communication with the CNS component but instead relies on the CNS-CSI for any storage provisioning operations. Unlike the CNS-CSI, the pvCSI does not require infrastructure credentials. It is configured with a service account in the vSphere Namespace.
The following illustrates how different components interact when a DevOps engineer performs a storage-related operation within the Tanzu Kubernetes cluster, for example creates a persistent volume claim (PVC).
The DevOps engineer creates a PVC using the command line on the Tanzu Kubernetes cluster. This action generates a matching PVC on the supervisor cluster and triggers the CNS-CSI. The CNS-CSI invokes the CNS creates volume API.
After the successful creation of a volume, the operation propagates back through the supervisor cluster to the Tanzu Kubernetes cluster. As a result of this propagation, users can see the persistent volume and the persistent volume claim in the bound state in the supervisor cluster. And they also see the persistent volume and the persistent volume claim in the bound state in the Tanzu Kubernetes cluster.
