Subscribe to our blog
Thanks for subscribing to the blog.
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:
- What Are Persistent Volumes in Kubernetes?
- Static vs. Dynamic Volumes
- Dynamic Provisioning for Kubernetes with NetApp Cloud Volumes ONTAP
What Are Persistent Volumes in Kubernetes?
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.
Static Volume Lifecycle
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.
Dynamic Volume lifecycle
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.
Static vs. Dynamic Volumes
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.
When to use static provisioning?
Consider the following use cases for static storage provisioning:
- Set parameters: Static provisioning is helpful in scenarios with predictable storage usage, i.e., when parameters, such as the size of the volume, are predefined.
- Existing volumes: A storage volume already provisioned in your storage device can be attached to a Kubernetes cluster as static volume.
- Shared volumes: Static volumes can be used if the same volume has to be shared across different applications. This can be in the same namespace or between applications in different namespaces.
When to use dynamic provisioning?
Consider the following use cases for dynamic storage provisioning:
- Flexibility: Dynamic provisioning is helpful when you need flexibility, i.e., to meet changing usage demands. Storage size can also differ between applications, so a set static volume size will not be appropriate.
- Infrastructure-as-Code: Use cases where the volumes are created automatically using scripts or CI/CD tools would also need dynamic provisioning.
- Optimization: Helps optimize storage cost as the volumes are not pre-provisioned to utilize storage. This is especially helpful in cloud environments where you are charged for storage in a pay-as-you-go model.
Advantages of Dynamic 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.
Cloud Storage Cost
Dynamic Provisioning for Kubernetes with NetApp Cloud Volumes ONTAP
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:
- Data protection and resiliency through application-aware, point-in-time NetApp Snapshot copies and Cloud Volumes ONTAP’s dual-node high availability configuration
- Quick and efficient persistent volume cloning
- Data mobility to move or replicate PVs between different clusters using NetApp SnapMirror® data replication.
- Reduce storage consumption 50-70% via storage efficiency features like deduplication, compression, and thin provisioning as well as automatic tiering of infrequently-used block storage to lower-cost object storage and back use-based demand.
- Single-pane management of PVs across multi- and hybrid cloud Kubernetes deployments NetApp Cloud Manager.
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.