Be familiar with several concepts essential to the vSphere Cloud Native Storage environment.

Components of Cloud Native Storage environment.

Kubernetes Cluster
In the Cloud Native Storage environment, you can deploy a generic Kubernetes cluster in a cluster of virtual machines. On top of the Kubernetes cluster, you deploy your containerized applications. Applications can be stateful and stateless.
Note: For information on supervisor clusters and TKG clusters that you can run in vSphere with Tanzu, see the vSphere with Tanzu Configuration and Management documentation.
Pod
A pod is a group of one or more containerized applications that share such resources as storage and network. Containers inside a pod are started, stopped, and replicated as a group.
Container Orchestrator
Open-source platforms, such as Kubernetes, for deployment, scaling, and management of containerized applications across clusters of hosts. The platforms provide a container-centric infrastructure.
Stateful Application
As containerized applications evolve from stateless to stateful, they require persistent storage. Unlike stateless applications that do not save data between sessions, stateful applications save data to persistent storage. The retained data is called the application's state. You can later retrieve the data and use it in the next session. Most applications are stateful. A database is as an example of a stateful application.
PersistentVolume
Stateful applications use PersistentVolumes to store their data. A PersistentVolume is a Kubernetes volume capable of retaining its state and data. It is independent of a pod and can continue to exist even when the pod is deleted or reconfigured. In the vSphere environment, the PersistentVolume objects use vSphere virtual disks of the First Class Disk (FCD) type or vSAN file shares as their backing storage. First Class Disks are also referred to as Improved Virtual Disks (IVD) or managed virtual disks.
  • Virtual disks support volumes that are mounted as ReadWriteOnce. These volumes can be used only by a single Pod in Kubernetes.

    Starting with vSphere 7.0, you can use the vSphere encryption technology to protect FCD virtual disks that back persistent volumes. For more information, see Use Encryption with Cloud Native Storage.

  • vSAN file shares support ReadWriteMany volumes that are mounted by many nodes. These volumes can be shared between multiple Pods or applications running across Kubernetes nodes or across Kubernetes clusters. For information about possible configurations with file shares, see Using vSAN File Service to Provision File Volumes.
StorageClass
Kubernetes uses a StorageClass to define different tiers of storage and to describe different types of requirements for storage backing the PersistentVolume. In the vSphere environment, a storage class can be linked to a storage policy. As a vSphere administrator, you create storage policies that describe different storage requirements. The VM storage policies can be used as a part of StorageClass definition for dynamic volume provisioning.

The following sample YAML file references the Gold storage policy that you created earlier using the vSphere Client. The resulting persistent volume VMDK is placed on a compatible datastore that satisfies the Gold storage policy requirements. 

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: gold-sc
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: csi.vsphere.vmware.com
parameters:
  storagepolicyname: "Gold"
PersistentVolumeClaim
Typically, applications or pods can request persistent storage through a PersistentVolumeClaim. The PersistentVolumeClaim specifies the type and class of storage, the access mode, either ReadWriteOnce or ReadWriteMany, and other parameters for the PersistentVolume. The request can then dynamically provision the corresponding PersistentVolume object and the underlying virtual disk or vSAN file share in the vSphere environment.
Once the claim is created, the PersistentVolume is automatically bound to the claim. Pods use the claim to mount the PersistentVolume and access storage.
When you delete this claim, the corresponding PersistentVolume object and the underlying storage are deleted. 
kind: PersistentVolumeClaim
metadata:
 name: persistent-VMDK
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 5Gi
 storageClassName: gold-sc