Configure topology-aware volume provisioning

Learn how to use the Kubernetes Container Storage Interface (CSI) topology feature to control where volumes are provisioned based on availability zones.

In multi-zone cloud environments, this feature enhances fault tolerance and performance by limiting volume access to specific nodes within a designated region or zone. Topology-aware provisioning uses the waitForFirstConsumer volume binding mode, which delays volume creation until Kubernetes schedules the workload. This ensures the volume is provisioned in the correct location relative to the pod that consumes it.

Prerequisites

  • Kubernetes v1.17 or a later version.

  • Topology labels on Kubernetes nodes. Most Kubernetes distributions create these labels by default during installation.

  • WEKA Operator v1.7.0 or a later version.

1. Confirm topology labels on Kubernetes nodes

Verify that your Kubernetes nodes have the required topology labels. The following command checks for topology.kubernetes.io/region and topology.kubernetes.io/zone labels on all nodes in the cluster.

$ kubectl get nodes -Ltopology.kubernetes.io/region -Ltopology.kubernetes.io/zone

Example output

NAME             STATUS   ROLES                       AGE   VERSION        REGION      ZONE
54.160.132.190   Ready    control-plane,etcd,master   46m   v1.33.4+k3s1   us-east-1   us-east-1a
54.161.26.50     Ready    worker                      45m   v1.33.4+k3s1   us-east-1   us-east-1b
54.162.121.142   Ready    worker                      45m   v1.33.4+k3s1   us-east-1   us-east-1b
54.167.56.31     Ready    control-plane,etcd,master   46m   v1.33.4+k3s1   us-east-1   us-east-1a
54.235.34.153    Ready    worker                      45m   v1.33.4+k3s1   us-east-1   us-east-1b
54.89.113.136    Ready    control-plane,etcd,master   46m   v1.33.4+k3s1   us-east-1   us-east-1a

In this example, the cluster has six nodes distributed across two availability zones: us-east-1a and us-east-1b.

2. Create a StorageClass with WaitForFirstConsumer

A StorageClass volumeBindingMode can be set to Immediate or WaitForFirstConsumer. For topology-aware provisioning, you must use WaitForFirstConsumer to delay volume creation until the consuming workload is scheduled.

For more advanced control, you can add the allowedTopologies parameter to the StorageClass manifest. This parameter restricts volume provisioning to a specific list of zones, ensuring that volumes are only created in those predefined locations.

The following manifest defines a StorageClass named weka-topology-aware with the correct binding mode.

Create the StorageClass.

3. Create a PersistentVolumeClaim (PVC)

To demonstrate the delayed binding, create a PVC without a corresponding workload.

Create the PVC.

Examine the PVC status.

Observe that the PVC status is Pending. The persistentvolume-controller waits for a workload to consume the PVC before provisioning and binding the volume.

Example description of the pending PVC


4. Define and create a workload

To trigger volume provisioning, define a workload that consumes the PVC. The following Pod manifest uses spec.affinity to specify its preferred deployment location, ensuring it is scheduled in the correct zone.

Create the Pod and then check the status of both the Pod and the PVC.

After the Pod is scheduled and running, the PVC status changes to Bound, indicating that the volume has been provisioned and is accessible to the Pod.

Last updated