Cloud Native storage includes design considerations for stateful workloads that require persistent storage provided by vSAN storage.

In Kubernetes, a Volume is a directory on a disk that is accessible to the containers inside a pod. Kubernetes supports many types of volumes. The Cloud Native storage design focuses on the vSAN storage design required to support dynamic volume provisioning and does not address different ways to present a volume to a stateful application.

vSAN Storage Policies:

The Telco Cloud Platform vSAN storage design provides the basis for container storage and has the following benefits:

  • Optimizes the storage design to meet the diverse needs of applications, services, administrators, and users.

  • Strategically aligns business applications and the storage infrastructure to reduce costs, boost performance, improve availability, provide security, and enhance functionality.

  • Provides multiple tiers of storage to match application data access to application requirements.

  • Designs each tier of storage with different performance, capacity, and availability characteristics.

vSAN storage policies define storage requirements for the StorageClass. Cloud Native persistent storage or volume (PV) inherits performance and availability characteristics made available by the vSAN storage policy. These policies determine how the storage objects are provisioned and allocated within the datastore to guarantee the required level of service. Kubernetes StorageClass is a way for Kubernetes admins to describe the “classes” of storage available for a Tanzu Kubernetes cluster. Different StorageClasses map to different vSAN storage policies.

Figure 1. Cloud Native StorageClass Mapping to vSAN

Storage Access Modes

Cloud Native persistent storage or a volume in Kubernetes is mounted with a certain access mode. Three possible access modes are as follows:

Access Mode

CLI Abbreviation




The volume can be mounted as read-write by a single node.



The volume can be mounted read-only by many nodes.



The volume can be mounted as read-write by many nodes.

RWO is the most common access mode for cloud native Stateful workloads. RWO volumes have 1:1 relation to a Pod. RWX volumes provide storage shared by multiple Pods with all Pods able to write to it. The difference between RWO and RWX relates to mounting the same filesystem on multiple hosts, which requires support for features such as distributed locking. The vSphere Cloud Storage Interface (CSI) based driver provisions only block-based Persistent Volumes on vSAN, which are RWO.

Design Decision

Design Justification

Design Implication

Define a default StorageClass for all workloads in a Tanzu Kubernetes cluster.

Default StorageClass allows Kubernetes users that do not have strict storage requirements to consume persistent storage easier, without knowing the underlying implementation.

Performance-sensitive workloads might be incorrectly classified if a Kubernetes user is left out of the StorageClass in a persistent volume claim.

Use the vSphere CSI provisioner for all RWO Persistent Volume Claims (PVC).

CSI provider is the out-of-tree storage provider implementation for vSphere and offers rich sets of capabilities compared to in-tree vSphere provisioner.

Storage Provisioner is defined as part of StorageClass set manually.