Skip to content

Storage

Overview

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 Add Shared Volume

  • Provide a Name for the volume, specify the Storage Class (optional) and Size. The system applies the default value if storage class is not specified

  • Enter the mount path that will be used by the containers in the workload to access the volume. Users are allowed to add multiple mount path(s) if required
  • Select the Access Modes for the specified mount path(s) from the drop-down. ReadWriteOnce, ReadOnlyMany, and ReadWriteMany are the three available access modes. If none of the access modes is selected, ReadWriteMany mode is applied by default

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

Workload Wide Shared Volumes