Dynamic Volume Provisioning for Kubernetes and OpenShift

Dynamic Volume Provisioning for Kubernetes and OpenShift

In traditional IT environments, provisioning a volume for use by an application can take significant time, and sometimes requires input by multiple teams – for example a storage team to set up the volume, and an operations team to mount it on appropriate nodes.

For a developer trying to deploy an application, these delays can cause frustrating context switches while he/she awaits for the storage to become available. The time wasted causes other dependent processes to be delayed, and reduces productivity.

Declarative and Composable Storage

Storage resources should be declared and composed just like all other resources required by applications and services. This allows storage resources and services to be deployed and provisioned as part of application instantiation through orchestrators.

Feature Spotlight: StorageOS Dynamic Volume Provisioning

StorageOS delivers dynamic volume provisioning using Kubernetes Storage Classes and Persistent Volumes Claims. It allows developers to self-service provision storage as required. When StorageOS is deployed, persistent volumes become part of the definition of the application, using the same declarative configuration syntax we use to manage application containers themselves.

The power of this approach is in increased agility. Not only can developers see instant feedback on an idea, but they can iterate on it too. If, after deploying a database, a second volume is found to be necessary for transaction logs, this can be accomplished quickly and without prior planning. Further, using declarative storage allows developers to automate all the storage provisioning as part of a CI/CD pipeline.

From a business perspective this translates to faster, better results, increased productivity and fewer delays.

How it Works

StorageOS clusters aggregate available node storage into a pool. Our containers use the node path /var/lib/storageos, and any storage available under this mount point is included in the pool. In a default install, this uses storage on the root partition, although of course we recommend that for production deployments, organizations mount purpose-built volumes to nodes to ensure deterministic performance and guard against root disks filling up.

When a developer wants to deploy an application, they include any requests for persistent storage as part of the application definition (in the yaml manifests common to Kubernetes and derivatives, for example). StorageOS dynamically creates the volume, and mounts the volume into the application container at the desired mount point. If the container crashes, upon restart, its data will still be present. If the node crashes, StorageOS replication will ensure that the volume remains available and the application can continue without downtime. Multiple volumes can be mounted into a container at different mount points, allowing flexible configurations.

Learn more about StorageOS features or download StorageOS for free to try dynamic volume provisioning.


Author: Paul Sobey

Paul Sobey is Head of Product at StorageOS. Paul has worked as a systems and infrastructure engineer for over 15 years, responsible for deploying cloud and on-premises infrastructure as well as deploying Kubernetes and containers in production.

  • Customer Case Study: StorageOS provides MSP, Civo with Cloud Native StorageRead Now

  • Blog: Using the RabbitMQ Kubernetes Operator with Persistent DataRead Now

  • Performance Benchmarking Cloud Native Storage Solutions for KubernetesDownload Now

  • Webinar: Register for Accelerating Kubernetes Onboarding and Application Transformation on 18th August, 2021 at 4pm (BST)Register Now