Illumina Innovates with Rancher and Kubernetes
To provide stateful workloads with vSphere storage, we recommend creating a vSphereVolume storage class. This practice dynamically provisions vSphere storage when workloads request volumes through a persistent volume claim.
In order to provision vSphere volumes in a cluster created with the Rancher Kubernetes Engine (RKE), the vSphere cloud provider must be explicitly enabled in the cluster options.
Note: The following steps can also be performed using the kubectl command line tool. See Kubernetes documentation on persistent volumes for details.
Note:
The following steps can also be performed using the kubectl command line tool. See Kubernetes documentation on persistent volumes for details.
kubectl
Under Provisioner, select VMWare vSphere Volume.
Optionally, specify additional properties for this storage class under Parameters. Refer to the vSphere storage documentation for details.
Click Save.
test-volume
Enter the required Capacity for the volume. Then click Define.
Assign a path in the Mount Point field. This is the full path where the volume will be mounted in the container file system, e.g. /persistent.
/persistent
Click Launch to create the workload.
touch /<volumeMountPoint>/data.txt
Inspect the contents of the directory where the volume is mounted by entering ls -l /<volumeMountPoint>. Note that the file you created earlier is still present.
ls -l /<volumeMountPoint>
You should always use StatefulSets for workloads consuming vSphere storage, as this resource type is designed to address a VMDK block storage caveat.
Since vSphere volumes are backed by VMDK block storage, they only support an access mode of ReadWriteOnce. This setting restricts the volume so that it can only be mounted to a single pod at a time, unless all pods consuming that volume are co-located on the same node. This behavior makes a deployment resource unusable for scaling beyond a single replica if it consumes vSphere volumes.
ReadWriteOnce
Even using a deployment resource with just a single replica may result in a deadlock situation while updating the deployment. If the updated pod is scheduled to a node different from where the existing pod lives, it will fail to start because the VMDK is still attached to the other node.