Why PVCs are being deleted and how to create role mappings with OIDC


I am setting up a new ECK instance using the Operator and I have two questions that I can’t find an answer for.

1- on this documentation page https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-volume-claim-templates.html, there is a paragraph that says:

ECK automatically deletes PersistentVolumeClaim resources if they are not required for any Elasticsearch node. The corresponding PersistentVolume may be preserved, depending on the configured storage class reclaim policy.

I don’t understand the reason behind this. I have defined a storageClass with a retain policy, so my PVs are never deleted. But as the doc says, when I bring down my instance, the PVCs are deleted even though ECK is using statefullsets. It is common practice to leave those PVCs and you manually have to delete them. By not deleting them, you can recreate your instance and it will reuse those PVCs and obviously also the same PVs. So I can I reuse the same PVs in a shutdown-restart scenario?

2- I am using Azure AD as an OpenID connect authenticator and that works. But I need to define a role mapping in order to give data access to my user. According to this page https://www.elastic.co/guide/en/elasticsearch/reference/current/oidc-role-mapping.html, the only way to add a role mapping with OIDC is to use the API:

Is there a way to do this in an automated fashion, once the pods are running? I am using Helm to generate the various yaml files and apply them...

Thank you

Please open 2 different threads for those different questions :slight_smile:

For the PVC question:

  • Indeed, we delete PVCs by default because it matches what most people want to do. You can watch this Github issue that describes a potential setting to change that behaviour: https://github.com/elastic/cloud-on-k8s/issues/2328.
  • In the meantime, for the shutdown/restart use case we also put together a script that recreates a cluster from existing retained PVs, even though there are no PVCs anymore.

For question 2 and automating API calls:

  • This is not currently possible. One way would be to spin up your own Kubernetes Job alongside the Elasticsearch resource, that would wait until the cluster is available then perform the required API calls. We're thinking about making this an ECK feature but it's not available yet.