CrashLoopBackOff on postgresql bitnami helm chart-CodePudding

I know there have been already a lot of questions about this, and I read already most of them, but my problem does not seem to fit them.

I am running a postgresql from bitnami using a helm chart as described below. A clean setup is no problem and everything starts fine. But after some time, until now I could not find any pattern, the pod goes into CrashLoopBackOff and I cannot recover it whatever I try!

Helm uninstall/install does not fix the problem. The PVs seem to be the problem, but I do not know why. And I do not get any error message, which is the weird and scary part of it.

I use a minikube to run the k8s and helm v3.

Helm chart:

CodePudding user response：

I really how nobody else runs across this, but finally I found the problem and for once it was not only between the chair and the monitor, but also RTFM was involved.

As mentioned I am using minikube to run my k8s cluster which provides PVs stored on the host disk. Where it is stored you may ask? Exaclty, here: /tmp/hostpath-provisioner/default/data-sessiondb-0/data/. You find the problem? No, I also took some time to figure it out. WHY ON EARTH does minikube use the tmp folder to store persistant volume claims?

This folder gets autom. cleared every now and so on.

SOLUTION: Change the path and DO NOT STORE PVs IN tmp FOLDERS.

They mention this here: https://minikube.sigs.k8s.io/docs/handbook/persistent_volumes/#a-note-on-mounts-persistence-and-minikube-hosts and give an example.

But why use the "dangerous" tmp path per default and not, let's say, data without putting a Warning banner there?

Sigh. Closing this question ^^

--> Workaround: https://github.com/kubernetes/minikube/issues/7511#issuecomment-612099413

Github issues to this topic:
My Github issue for clarification in the docs: https://github.com/kubernetes/minikube/issues/13038#issuecomment-981821696