The Cloud Native storage design includes design considerations for stateful workloads that require persistent storage provided by SAN 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 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.

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:

vSAN storage policies define storage requirements for your 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 by the Cloud Admin. Different StorageClasses map to different vSAN storage policies.

The following diagram is an example mapping of vSAN policy and Kubernetes StorageClass:

Figure 1. Cloud Native StorageClass Mapping to vSAN
Cloud Native StorageClass Mapping to vSAN

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 the most common access mode for cloud native Stateful workloads. RWO volumes have 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. The vSphere Cloud Storage Interface (CSI) based driver provisions only block-based Persistent Volume, which is RWO. RWX can be accomplished using external NFS.

There are a few ways to enable NFS. NFS Server Provisioner is an out-of-tree provisioner that enables dynamically serving NFS persistent volumes (PV) from a single RWO persistent volume using existing Storage Class and share it as RWX Storage Class. For a sample implementation, see the NFS Server Provisioner documentation. NFS Server Provisioner is not intended for connecting to an existing NFS server. If an NSF server exists, use the CSI NFS Provisioner instead.

Figure 2. NFS Server Provisioner
NFS Server Provisioner

Cloud Native Storage Design Recommendations

Design Recommendation

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 consuming 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.

provisioner: csi.vsphere.vmware.com

Use NFS Server Provisioner or NFS Client Provisioner to enable dynamic serving NFS Persistent Volumes (PV) from any other volume type.

NFS Server Provider maps a single RWO persistent volume from existing Storage Class and share it as RWX Storage Class.

Default StatefulSet includes only a single replica. If a Pod crashes, NFS server will not be available.

NFS Provisioners are upstream plugins and follow the community support model.