Configure MSR image storage

If your MSR deployment has a single replica, you can continue to use the local filesystem to store your Docker images. If, though, your MSR deployment has multiple replicas, make sure that all of the replicas are using the same storage back end for high availability.

Whenever a user pulls an image, the MSR node serving the request must have access to that image.

Storage back ends

MSR supports the following storage systems:

Persistent volume

  • NFS

  • Bind mount

  • Volume

Cloud storage providers

  • Amazon S3

  • Microsoft Azure

  • OpenStack Swift

  • Google Cloud Storage

  • Alibaba Cloud Object Storage Service

You can configure your storage back end at the time of MSR installation or upgrade. To do so, specify the parameter in your custom resource manifest or Helm chart values.yaml file with one of the following values, as appropriate:

  • "persistentVolume"

  • "azure"

  • "gcs"

  • "s3"

  • "swift"

  • "oss"

The following table details the fields that you can configure in the section of the custom resource manifest and Helm chart values.yaml file:




The storageClass for the persistentVolume.


The access mode for the persistentVolume.


The size of the persistentVolume.

Local filesystem

The default MSR back end is persistentVolume.

You must configure a default StorageClass on your cluster that supports the dynamic provisioning of persistent volumes. The StorageClass must support the provisioning of ReadWriteOnce and ReadWriteMany volumes.

To verify the current default StorageClass:

kubectl get sc

Example output:

standard (default)   Delete          Immediate           false                  33d

MSR deployments with high availability must use either NFS or another centralized storage back end to ensure that all MSR replicas have access to the same images.

To verify the amount of persistent volume space that is in use:

kubectl -n <NAMESPACE> exec service/<RELEASE_NAME> -- df