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 backend for high availability.

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

Storage backends

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 backend at the time of Helm chart installation or upgrade. To do so, specify in your Helm chart the parameter with one of the following values, as appropriate:

  • "persistentVolume"

  • "azure"

  • "gcs"

  • "s3"

  • "swift"

  • "oss"

The section of values.yaml in your Helm chart contains the following detailed storage configuration information:




The storageClass for the persistentVolume.


The access mode for the persistentVolume.


The size of the persistentVolume.

Local filesystem

The default MSR backend 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 backend 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