One of the things I noticed is that Helm charts that require persistence (e.g. Postgres) contain a persistent volume claim but not a default persistent volume.

It seems that it is assumed that this should not be part of the Helm chart and should be provisioned separately.

Is there some best practice or idea behind the lack of a pv (maybe with templated options) or at least a default one? This would allow running the chart out of the box.

CodePudding user response：

Stateful apps' helm charts assume volumes were provisioned beforehand using storage static provisioning or on-demand using dynamic provisioning.

Storage provisioning includes storage allocation, creation of PV object and binding it to the storage. This is usually done manually by storage admins for static provisioning or automatically by default storage class for dynamic provisioning.

If you install a helm chart in managed Kubernetes cluster on cloud or even Minikube, there's default storage class which will dynamically provision the storage based on helm chart's PVC and bind the provisioned PV to it. (request for storage)

If you prefer the chart to use statically provisioned PVs, you should disable using default storage class in chart's values.yaml or even specify the volume to be used there (the exact syntax and options may change from chart to chart, but the idea is the same).

Using dynamic provisioning has many advantages over static provisioning which I summarized in my blog post on Dynamic Provisioning of Kubernetes Storage