Skip to content



Once applications are developed with a containerized architecture, they can be deployed anywhere i.e. public cloud, hybrid, on-premises without any change to the underlying code.

Many production applications are stateful, i.e. require some sort of external storage and support for storing state is critical for the application.

An application operating in a cluster can be very dynamic i.e. containers are constantly being created and destroyed, depending on the load and on the specifications of the developers. In addition, pods and containers can self-heal and replicate.

However, a persistent storage solution cannot afford this emphemeral behavior and cannot be bound to the rules of being dynamically created and destroyed. Persistent storage solutions also should not be proprietary to a specific infrastructure provider.

Workload Wide Shared Volumes

Workloads based on the "Workload Wizard"

A workload can comprise of multiple containers and they may all need to access a shared volume.

  • Select your workload from the list of workloads
  • Click on the Containers Tab
  • Expand "Workload-wide, Shared Volumes"
  • Click in "Add Shared Volume"

  • Provide a "name" for the volume, specify a "size" and the "mount path" that will be used by the containers in the workload to access the volume.

You can create multiple workload-wide shared volumes for a given workloads. These volumes are dynamically created on clusters when the workload is published.

Workload Wide Shared Volumes

Container Specific Volumes

A container may need access to its own private storage volume to operate.

  • Select the container in the workload
  • Click on Volumes
  • Provide a "name" for the volume, specify a "size" and the "mount path" that will be used to access it.
  • Select whether the volume needs to be persistent.

Containers may be restarted if they have issues. If storage needs to persist across restarts, a persistent volumen should be used.

Container Volumes