The Cloud Native storage design section includes design considerations for stateful workloads that require persistent storage. The vSAN design forms the basis for the Cloud Native Storage design.

In Kubernetes, a Volume is a directory on a disk that is accessible by the containers in 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. This design does not address different ways to present a volume to a stateful application.

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. Not every application requires expensive, high-performance, highly available storage, so designing different storage tiers reduces cost.

vSAN storage policies define storage requirements for your storage. Cloud Native persistent storage or volume (PV) inherits performance and availability characteristics from the vSAN storage policy.

Kubernetes admins use Kubernetes StorageClass objects to describe the storage “classes” available for a Tanzu Kubernetes cluster. Different StorageClasses can map to different vSAN storage policies.

Note:

  • By default, only a single vSAN storageclass is created on the Tanzu Kubernetes clusters that consume the vSAN default storage policy. Platform owners can create and expose different storage classes with storage policies as required.

  • While this design uses vSAN, any supported storage solution that meets the characteristics of this storage design can be used. For best practices, see the vendor documentation.

Cloud Native Storage Access Modes

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

Access Mode

CLI Abbreviation

Description

ReadWriteOnce

RWO

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

ReadOnlyMany

ROX

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

ReadWriteMany

RWX

The volume can be mounted as read-write by many nodes.
RWO is a common access mode for cloud native Stateful workloads. RWO volumes have a 1:1 relation to a Pod in general.

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.

With vSAN 7.0 and lower versions, the vSphere Cloud Storage Interface (CSI) based driver provisions only block-based Persistent Volume, which aligns with RWO storage access. In this scenario, a VMDK is created and attached to the TKG VM.

RWX can be accomplished using external NFS, or with vSAN 7.0 and later versions. By enabling the vSAN File Service feature, a single vSAN cluster can be used for both RWO and RWX support. A Container File Volume (CFV) is created within vSAN File Services when a RWX volume is created using the vSphere CSI driver (that is backed by a vSAN datastore).

Note:

There are limitations to how many RWX PVs can be provisioned when using the vSphere-CSI driver when using vSANFS as the backing storage.

For details, please refer to the configuration maximums page.