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 MSR installation or upgrade. To do so, specify the registry.storage.backend 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 registry.storage.persistentVolume section of the custom resource manifest and Helm chart values.yaml file:

Field

Description

storageClass

The storageClass for the persistentVolume.

accessMode

The access mode for the persistentVolume.

size

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:

NAME                 PROVISIONER                RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
standard (default)   k8s.io/minikube-hostpath   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