The following is a table of information regarding datastores:
|
Deployment topology/storage technology |
vSAN datastores |
VMFS over NFS/iSCSI/FC datastores |
|
Single vSphere compute cluster (single AZ, or multiple AZs if using RPs) with a datastore local to a single vSphere compute cluster |
|
|
|
Multi-vSphere compute clusters (multiple AZs) with datastore(s) local to each vSphere compute cluster |
|
|
|
Multi-vSphere compute clusters (multiple AZs) with datastore(s) shared across all vSphere compute clusters |
|
|
Following are the steps to provision Static PV:
- Manually create a VMDK file
- Create a PV referencing the aforementioned VMDK file
- Create a PVC
- Deploy a stateful POD or StatefulSets by using a reference to the PVC
Following are the steps for Dynamic PV provisioning:
- Create a PVC (vCP K8s storage plugin; a hatchway will automatically create PV and VMDK files)
- Deploy stateful POD or StatefulSets using a reference to PVC
The following are some vSAN considerations in regards to PKS/NSX-T:
- Using vSAN, a vSphere cluster must start with a minimum of three ESXi hosts to guarantee data protection (in this case, for RAID1 with failure to tolerate set to 1)
- A PKS AZ does not map with the vSAN fault domain
- A PKS with a single compute cluster is currently supported with vSAN (all ESXi hosts are located in the same site)
- Caution: A PKS with a vSAN stretched cluster is not a supported configuration, as of right now (no mapping of AZs with the vSAN fault domain)
- A PKS with multiple compute clusters is not a supported configuration with a vSAN-only datastore
- Master and worker nodes can be created across the different ESXi clusters (BOSH tile allows you to specify multiple persistent and ephemeral datastores for the VMs)
- PV VMDK disks are created for only one vSAN datastore (and no replication across the different vSAN datastores will be performed automatically)
Data centers maintain independent PKS instances, NSX deployments, Kubernetes (K8s) clusters, and vSphere infrastructures. A Global Server Load Balancer (GSLB), which is available through a third party, monitors the availability of the sites' K8s cluster API and PKS controller API. Operations and development direct API requests to the GSLB virtual server URL for creating and managing K8s clusters and deploying apps. Manually deployed apps (through kubectl, for instance) are not automatically replicated between environments and need to be redeployed following a failover to site B.
You can configure a CI/CD automation server to execute build pipelines against the K8s' URL in each environment or single builds against the GSLB virtual server URL. Harbor policy based replication, a built-in feature, manages cloning images to the standby location. You can replicate the datastore(s) between environments to support PV. Following a site A failure, the pods are redeployed at site B, mounting the original persistent volume's VMDK file.