TKG cluster workloads may require persistent storage. Refer to the information in this topic for vSphere storage concepts and considerations for TKG Service clusters.
vSphere Storage Policies for TKG Service Clusters
To provide persistent storage resources to TKG Service clusters, a vSphere administrator configures vSphere storage policies that describe different storage requirements. The administrator then adds one or more storage policies to the vSphere Namespace where TKG clusters will be deployed. Storage policies assigned to a vSphere Namespace dictate how TKG cluster nodes and workloads are placed in the vSphere storage environment, and determine which datastores TKG clusters can access and use for persistent storage.
When a vSphere storage policy is assigned to a vSphere Namespace, the system creates matching Kubernetes storage classes for that vSphere Namespace. The matching Kubernetes storage classess are propagated to TKG clusters provisioned in that vSphere Namespace.
In a TKG cluster, each storage class has two editions, one with the Immediate and another with the WaitForFirstConsumer binding mode. The edition you choose depends on your requirements. See Storage Class Editions for TKG Service Clusters.
How TKG Service Clusters Integrate with vSphere Storage
To integrate with the Supervisor and vSphere storage, TKG clusters use Paravirtual CSI (pvCSI).
The pvCSI is the version of the vSphere CNS-CSI driver modified for TKG clusters. The pvCSI resides in the TKG cluster and is responsible for all storage related requests originating from the TKG 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.
How a Persistent Volume is Created
The diagram illustrates how different components interact for storage related operations within a TKG cluster, such as creating a persistent volume claim (PVC).
The DevOps engineer creates a PVC using kubectl on the TKG cluster. This action generates a matching PVC on Supervisor and triggers the CNS-CSI, which invokes the CNS create volume API.
After successful creation of a volume, the operation propagates back through the Supervisor to the TKG cluster. Cluster users can see the persistent volume and the persistent volume claim in the bound state in the Supervisor. And they also see the persistent volume and the persistent volume claim in the bound state in the TKG cluster.
