Volume claim templates

By default, the operator creates a PersistentVolumeClaim with a capacity of 1Gi for each pod in an Elasticsearch cluster to prevent data loss in case of accidental pod deletion. For production workloads, you should define your own volume claim template with the desired storage capacity and (optionally) the Kubernetes storage class to associate with the persistent volume.

Important

The name of the volume claim must always be elasticsearch-data, unless you set up a corresponding volume mount yourself. Refer to Use a custom volume claim name.

spec:
  nodeSets:
  - name: default
    count: 3
    volumeClaimTemplates:
    - metadata:
        name: elasticsearch-data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 5Gi
        storageClassName: standard
		
  1. Do not change this name unless you set up a volume mount for the data path. Refer to Use a custom volume claim name.
  2. standard is an example. Replace it with the name of a storage class that exists in your Kubernetes cluster, or omit storageClassName to use the default storage class. ECK does not create storage classes.

If you name the volume claim something other than elasticsearch-data, add a volume mount with the same name to the elasticsearch container, and mount it at /usr/share/elasticsearch/data. This is the default data path of Elasticsearch in ECK, so you do not need to set path.data. ECK rejects a volume claim that is not mounted in any container.

spec:
  nodeSets:
  - name: default
    count: 3
    podTemplate:
      spec:
        containers:
        - name: elasticsearch
          volumeMounts:
          - name: my-data
            mountPath: /usr/share/elasticsearch/data
    volumeClaimTemplates:
    - metadata:
        name: my-data
      spec:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 5Gi
		
Warning

Do not mount the volume at another path or set path.data yourself. If the mount path differs from the data path, Elasticsearch starts normally but writes its data to the ephemeral storage of the container, and the data is lost when the Pod is recreated.

ECK automatically deletes PersistentVolumeClaim resources if the owning Elasticsearch nodes are scaled down. The corresponding PersistentVolumes may be preserved, depending on the configured storage class reclaim policy.

In addition, you can control what ECK should do with the PersistentVolumeClaims if you delete the Elasticsearch cluster altogether through the volumeClaimDeletePolicy attribute.

apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
  name: es
spec:
  version: 9.5.7
  volumeClaimDeletePolicy: DeleteOnScaledownOnly
  nodeSets:
  - name: default
    count: 3
		

The possible values are DeleteOnScaledownAndClusterDeletion and DeleteOnScaledownOnly. By default DeleteOnScaledownAndClusterDeletion is in effect, which means that all PersistentVolumeClaims are deleted together with the Elasticsearch cluster. However, DeleteOnScaledownOnly keeps the PersistentVolumeClaims when deleting the Elasticsearch cluster.

Warning

After you delete the cluster, do not delete any of the retained PersistentVolumeClaims. ECK does not check the integrity of the data on adopted PersistentVolumeClaims. Missing or damaged data can cause data loss or prevent master discovery. Recovery requires last-resort steps that can also lose data: restore a snapshot into a new cluster, or use the elasticsearch-node tool as described in Suspend Elasticsearch.

If you recreate a deleted cluster with the same name, namespace, and node sets as before, the existing PersistentVolumeClaims will be adopted by the new cluster.

If the storage class allows volume expansion, you can increase the storage requests size in the volumeClaimTemplates. ECK will update the existing PersistentVolumeClaims accordingly, and recreate the StatefulSet automatically. If the volume driver supports ExpandInUsePersistentVolumes, the filesystem is resized online, without the need of restarting the Elasticsearch process, or re-creating the Pods. If the volume driver does not support ExpandInUsePersistentVolumes, Pods must be manually deleted after the resize, to be recreated automatically with the expanded filesystem.

Kubernetes forbids any other changes in the volumeClaimTemplates, such as changing the storage class or decreasing the volume size. To make these changes, you can create a new nodeSet with different settings, and remove the existing nodeSet. In practice, that’s equivalent to renaming the existing nodeSet while modifying its claim settings in a single update. Before removing Pods of the deleted nodeSet, ECK makes sure that data is migrated to other nodes.

Warning

Don’t use emptyDir as it might generate permanent data loss.

If you are not concerned about data loss, you can use an emptyDir volume for Elasticsearch data:

spec:
  nodeSets:
  - name: data
    count: 10
    podTemplate:
      spec:
        volumes:
        - name: elasticsearch-data
          emptyDir: {}
		
Note

Besides the risk of data loss, emptyDir (or any volume that isn't a volumeClaimTemplates PVC) prevents ECK from determining the storage capacity of the affected nodes. On Elasticsearch 8.3 and later, the Elasticsearch resource then reports the ResourcesAwareManagement condition as False.

ResourcesAwareManagement indicates whether ECK could compute CPU, memory, and storage for all expected nodes so it can tell Elasticsearch the intended cluster topology. When the condition is False, ECK stops publishing that topology and removes any topology it published earlier. Without it, Elasticsearch may make less optimal topology-aware decisions. The condition is cluster-wide, so a single nodeSet using emptyDir sets it to False for the whole cluster. ECK still reconciles the Elasticsearch resource (StatefulSets, Pods, and CPU and memory settings) as usual.