Dynamic and Static Provisioning

User Guides for VMware Solutions
Audience
Public
Content Type
User Guides
Source Type
Documentation

Dynamic Provisioning is the method used to create persistent volumes for a Kubernetes application on-demand as it frees the Kubernetes administrator from having to pre-provision potentially many persistent volumes up front that the PVC can then claim when needed (i.e. static provisioning). Dynamic Provisioning entails creating a persistent volume claim that is matched to an application and a StorageClass. In fact, the StorageClass is the key construct which enables dynamic provisioning to be available as it includes the volume characteristics consumed by the developer and is defined and setup by the vCenter administrator.

The beauty of dynamic provisioning is two-fold: no storage is actually provisioned until the Kubernetes deployment is instantiated with a persistent volume claim - meaning that a data vVol or VMFS VMDK and its associated space are not consumed on the FlashArray until the Kubernetes application is in the process of being created. As environments grow, dynamic provisioning quickly becomes the only reasonable option to use as the alternative with static provisioning means that storage administrators have to manually create each persistent volume before it can be used, which does not scale as easily.

Let's break down a simple persistent volume claim YAML file into the important components for dynamic provisioning. There are certainly more options than what is shown here; many of which we will expand upon in later sections of this KB and overall guide:

apiVersion: v1

kind: PersistentVolumeClaim (1)

metadata:

  name: pvc-vvols-mysql (2)

spec:

  storageClassName: kubernetes-vvols (3)

  accessModes:

    - ReadWriteOnce (4)

  resources:

    requests:

      storage: 30Gi (5)
  1. kind: This where we designate what the YAML file is creating. In this case, we are creating a PVC.
  2. name: This is the name we provide our PVC. A Kubernetes deployment YAML file, for example, will reference this name to use this PVC if you provide this name.
  3. storageClassName: This is an optional field unless no default storageclass has been defined in your Namespace, in which case it is required. This field dictates what storageClass you want the persistent volume to use. The recommended way to create a StorageClass in Tanzu is via an SPBM policy and then assign that policy to a Namespace.
  4. accessModes: Today only ReadWriteOnce is supported for the FlashArray. This means that the persistent volume can only be attached to, and consumed by a single Kubernetes pod. We are optimistic that sometime in the future ReadWriteMany will also become a supported option. There are also numerous application-specific methods for mirroring data across multiple persistent volumes within something like a statefulset.
  5. storagerequest: This is where the user inputs how much storage they want the persistent volume to use when it is created. Persistent Volume expansion is supported once the PVC has been created and is covered in a later section of this KB.

    Static Provisioning, meanwhile is when a Kubernetes application is bound to a pre-existing Persistent Volume through a Persistent Volume Claim. Most commonly, Static Provisioning is used when a PV already containing relevant data for the application needs to be used in its course of operations. A system administrator may also manually provision one or more PVs that can later be used by a PVC so long as they match the specifications of what the PVC is looking for. It is obvious but is important to mention: while Static Provisioning certainly works; it does become more and more untenable as environments increase in size and scale as it requires system administrators to manually provision them to be used. After some additional concepts and examples are introduced, an example of using Static Provisioning to migrate a persistent volume between Tanzu Kubernetes Guest Clusters will be provided at the end of this guide.

    The below demo video provides a brief demonstration of the differences between dynamic and static provisioning:

    At this point we have covered the two methods behind how and when PVs are created for use. However, of equal if not more importance is defining their behavior when it comes time for the associated application to be deleted or migrated. The capability to retain, copy and move data from one Kubernetes instance to potentially many others is obviously of huge importance, and is the subject of the next section.