ECK Operator - unbound immediate PersistentVolumeClaims error

I'm using below spec and as per documenation, the standard storageClassName should be available as standard. But getting error:

  Warning  FailedScheduling  18s   default-scheduler  0/1 nodes are available: 1 pod has unbound immediate PersistentVolumeClaims.

I've installed the ECK 2.2.0 operator and below is the Elastic yaml

apiVersion: v1
kind: Namespace
  name: "elk"

kind: Elasticsearch
  name: quickstart
  namespace: elk
  version: 8.2.3
  - name: default
    count: 2
    - metadata:
        name: elasticsearch-data
        - ReadWriteOnce
            storage: 2Gi
        storageClassName: standard

Just to be sure: Whats in your kubectl get storageclass`?

Also kubectl describe pvc elasticsearch-data-quickstart-es-default-0 might be interesting.

was expecting the storageclass/pv would be automatically generated by the operator?
Or should a pv be generated separately?

kubectl -n elk get storageclass
local-path (default)   Delete          WaitForFirstConsumer   false                  59d

NO pvc was generated

As mentioned, I was just following the documenation & examples in the Elastic Quickstart

IMO the storageClassName depends on your Kubernetes distribution / provider, see the Kubernetes docs.

And if I remember correctly, you need to either pick an existing storage class or create the one you want to use (and it should also be an optional setting). Volume claim templates | Elastic Cloud on Kubernetes [2.2] | Elastic is probably a good starting point.

Agree in case of pure k8s implementation, but we are speaking about Elastic/ECK operator. If you look into similar operator providers like Splunk all of the pv is built-in

My feedback/request was, this is NOT the case in ECK operator and warning is not provided in the documentation. I could have created a PV and attached, but as mentioned would expect the docs to reflect similar

If you leave out the storage class in your manifest and if your cluster admin has set up a default storage class (which is not identified by the name standard but by an annotation on the storage class ) it will work without any explicit storage class setup.

Our Quickstart example does not have an explicit volumeClaimTemplate but the documentation you linked to Volume claim templates | Elastic Cloud on Kubernetes [2.2] | Elastic could indeed be improved as it does not explain where the standard storage class comes from. I will open an issue to get this updated.


thanks for that.