With microservices based architectures fast becoming the norm, choosing the right approach to provisioning your persistent storage is an important design decision.
In this blog, we'll go through the differences between static and dynamic provisioning for persistent storage, as well as the benefits and use cases for both methods.
This blog is part of our Introduction to Kubernetes series.
The topics we’ll cover here include:
PersistentVolume is a subsystem of Kubernetes that enables abstraction of how the storage for containers are provisioned and used. The associated constructs of Kubernetes for provisioning and consuming the storage are StorageClass, PersistentVolume, and PersistentVolumeClaim.
StorageClass: Administrators can use a StorageClass to specify the "classes" of storage available to provision PersistentVolumes. This would include details of the provisioner, quality of service, reclaim policy, etc.
Provisioner: The provisioner determines the volume plugin that needs to be used while provisioning PersistentVolumes using StorageClass. The provisioner could be any of the cloud or on-premises storage services, for e.g.: disk services in cloud, NFS shares, iSCSI. Vendors can also add support to their storage systems to Kubernetes using Container Storage Interface (CSI) plug-ins.
PersistentVolume (PV): Kubernetes Persistent Volume denote storage volumes that are provisioned using the storage classes. Administrators can either pre-provision the volumes or dynamically provision them as and when a request is received from the Pod during deployment. The API object for PV encapsulates the storage implementation from any of the storage provisioners defined by the storage class.
PersistentVolumeClaim (PVC): Kubernetes PVCs are used by Pods to request for PVs. The claims can indicate the desired storage capacity and access mode (ReadWriteMany, ReadWriteOnce, or ReadOnlyMany).
There are two options for provisioning and consuming persistent storage for a container—static or dynamic. Let’s take a closer look at both of these options.
With static volumes, the desired storage volumes are pre-provisioned by an administrator. They are created from the storage solution and made available through storage classes. When a pod needs storage, the volumes can be requested through a PVC.
If there is a static PV available in the cluster that matches the spec requested by the pod, it is bound to that PVC. These bound volumes are then mounted by the pod so that applications can access them.
The PV will remain bound to the pod during its lifecycle. Once the volume usage is completed the reclaim policy of the PVs will determine whether the volume can be retained, recycled or deleted.
With dynamic volumes, the storage volumes are created based on the PVC from the pod. The volumes are created for the storage class specified in the PVC. Note that these storage classes must be pre-configured in the cluster for the dynamic storage provisioning to succeed. It also requires the Kubernetes cluster to have the ‘DefaultStorageClass’ admission controller enabled.
Since the provisioning happens on demand, there are no limitations around the sizing as in the size of static volumes. Once the PV is created, the binding and reclaiming process is the same as that of a static volume.
For some time, the only options to attach storage in Kubernetes clusters were the native in-tree plug-ins and FlexVolume plug-ins. However, neither of these choices offered a scalable model for users that needed to attach storage systems that couldn’t readily use those plug-ins. Also, the availability of plug-ins was dependent on Kubernetes releases.
This issue was addressed with the introduction of CSI plug-ins, which provided a set of standard specifications that could be used by customers to write their own storage plug-ins. Both static and dynamic storage provisioning processes can leverage these CSI plug-ins to create persistent volumes in a storage device of customer’s choice. Use of the CSI plug-ins is now the recommended best practice.
Consider the following use cases for static storage provisioning:
Consider the following use cases for dynamic storage provisioning:
The need for persistent storage volumes for containers can be met with either static or dynamic provisioning. However, as the name indicates, static provisioning restricts your configuration options, and offers limited room for optimization. In fast changing environments, especially those deployed in the cloud, static provisioning is not often a good choice.
Dynamic provisioning provides flexibility in terms of storage configuration as well as optimization. With CSI storage plug-ins, you can easily use storage tiers in the cloud that meet the performance requirements of applications on the fly through dynamic provisioning. You can also get the benefits of low-cost storage in the cloud through native cloud storage tiering capabilities. It also seamlessly integrates with the existing DevOps processes for application delivery.
The table below compares the different features of static and dynamic storage provisioning at a high level.
Features |
Static Provisioning |
Dynamic provisioning |
Volume Sizing |
Fixed sizing |
Flexible sizing |
Provisioning mode |
Pre-provisioned |
On-demand |
Cloud Storage Cost |
High |
Low |
DevOps integration |
Complex |
Easy |
CSI Integration |
Supported |
Supported |
Volume Reclaim |
Supported |
Supported |
Cloud Volumes ONTAP extends NetApp ONTAP's capabilities to the cloud, delivering an enterprise-class storage management platform that can dynamically provision storage for your Kubernetes workloads using native AWS, Azure, and Google Cloud storage.
Via NetApp Astra Trident, an implementation of the CSI plug-in, Kubernetes clusters can gain access to Cloud Volumes ONTAP storage volumes to fulfill PVCs automatically and on-demand. Kubernetes clusters can then also benefit from the rest of Cloud Volumes ONTAP's industry-leading features and capabilities, including:
Learn more about how Cloud Volumes ONTAP supports Kubernetes Persistent Volume provisioning and management requirements of containerized workloads, and how Cloud Volumes ONTAP helps to address the challenges of containerized applications in these Kubernetes Workloads with Cloud Volumes ONTAP Case Studies.