Persistence and Storage

Cluster persistence is enabled by default, with 8 Gi allocated. To explicitly disable persistence, set persistence.enabled to false:

Without persistence, pods use ephemeral storage. All data is lost when a pod is deleted or rescheduled.

Specify a storage class and volume size to control the type and capacity of the underlying storage:

When storageClassName is omitted, Kubernetes uses the cluster’s default storage class. The size field accepts any valid Kubernetes quantity (for example, 20Gi, 100Gi, 1Ti).

If you have a PersistentVolumeClaim that was provisioned outside of the operator — for example, pre-provisioned by an administrator or restored from a snapshot — reference it with existingClaim:

When an existing claim is specified, the operator does not create a new PVC. The claim must exist in the same namespace as the GridGain9Cluster resource.

Beyond the main persistence volume, you can request additional persistent volumes for specific purposes. Common examples are separating cluster Raft logs (stored in /raft) or application logs (stored in /logs) from the primary data directory. Define them under persistence.additionalVolumes as a map of named volume specifications:

Each entry in the map accepts enabled, mountPath, size, storageClassName, and accessModes fields. Disabled entries are ignored.

Some storage providers create volumes owned by root, which prevents the GridGain process from writing to them when it runs as a non-root user. The operator can run an init container to fix ownership before the main container starts:

When volumePermissions is specified, the enabled field defaults to true. You can also override the init container image and resource allocation:

The storage.profile.memoryPercentage field controls what fraction of the container’s memory limit is allocated to the GridGain storage engine’s off-heap memory region. The default is 60:

The valid range is 1 to 100. Lower values leave more memory for the JVM heap and other processes in the container; higher values dedicate more memory to caching data pages. For development workloads with limited resources, reducing this to 40 can help avoid out-of-memory conditions. For large datasets, increasing it to 70 or above keeps more data in memory.