โš™๏ธConfigure persistence

Parameters

To configure the persistence of our Helm Charts, each component of the stack has a persistence field.

Here's the list of field:

yaml: values.override.yaml
laputa:
  persistence: # ...

curity:
  admin:
    persistence: # ...

postgresql:
  primary:
    persistence: # ...

mongodb:
  persistence: # ...

garage:
  persistence:
    meta:
      # ...
    data:
      # ...

layout-redis:
  master:
    persistence: # ...

laputa-redis:
  master:
    persistence: # ...

impersonate-redis:
  master:
    persistence: # ...

dataexecution-redis:
  master:
    persistence: # ...

In which, we've enabled and disabled the persistence of each component, based on the needs of the deployment. For example, most Redis doesn't need to be persisted and can be disabled.

Here's a common list of options for the persistence field:

subPath and mountPath have been purposely omitted from the above example. This is used internally to debug the Helm Chart.

We do not recommend editing subPath and mountPath.

Dynamic provisioning

To dynamically provision storage, we use a StorageClass. StorageClass is a Kubernetes resource defined by a storage provisioner, which is itself provided by the cloud provider, or by your Kubernetes administrator.

You can list the available provisioners with:

For the sake of the example, we will use local-path as our storage provisioner.

Your StorageClass should look like this:

To inspect the resource definition, you can run:

Behind the scenes of the Helm Chart, persistence is actually a PersistentVolumeClaimTemplate. This is used to generate a PersistentVolumeClaim for each replica of the StatefulSet.

To ask for a volume, simply set:

Upon deployment, the StatefulSet will create a PersistentVolumeClaim with the requested size, which will trigger the creation of a PersistentVolume.

Static provisioning

We highly recommend dynamic provisioning for production, for ease of use. You can always fallback to static provisioning if you need to.

For the sake of the example, we will use hostPath with a node selector. If you are interested in other options, you might be interested in checking out Container Storage Interface (CSI) Drivers.

To statically provision a volume, you need to create a PersistentVolume:

We bind the PersistentVolume to the node since the data is local to the node.

If you wish for an alternative that supports data migration, you would use a block storage provided by the cloud provider, or from your own storage infrastructure.

Apply it:

Simply set:

Last updated

Was this helpful?