2
votes

I'm using Helm to deploy postgres on Kubernetes cluster. I create a persistent volume and a persistent volume claim:

pv.yaml:


    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: task-pv-volume
      labels:
        type: local
    spec:
      storageClassName: manual
      capacity:
        storage: 10Gi
      accessModes:
        - ReadWriteMany
      hostPath:
        path: "/mnt/data"

pvc.yaml:


    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: task-pv-claim
    spec:
      storageClassName: manual
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 8Gi

and run helm with command:

helm install my-release stable/postgresql --set persistence.existingClaim=task-pv-claim

but Pods is in state CrashLoopBackOff. Logs of the pod say:


    postgresql 12:12:18.62 
    postgresql 12:12:18.62 Welcome to the Bitnami postgresql container
    postgresql 12:12:18.62 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-postgresql
    postgresql 12:12:18.62 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-postgresql/issues
    postgresql 12:12:18.63 Send us your feedback at [email protected]
    postgresql 12:12:18.63 
    postgresql 12:12:18.65 INFO  ==> ** Starting PostgreSQL setup **
    postgresql 12:12:18.73 INFO  ==> Validating settings in POSTGRESQL_* env vars..
    postgresql 12:12:18.73 INFO  ==> Loading custom pre-init scripts...
    postgresql 12:12:18.74 INFO  ==> Initializing PostgreSQL database...
    mkdir: cannot create directory ‘/bitnami/postgresql/data’: Permission denied
    postgresql 12:12:18.76 INFO  ==> Stopping PostgreSQL...

How can i fix it?

1
You mount the PV to the path /mnt/data, but your PSQL Instance searches for it in bitnami/postgresql/data. Maybe try setting bitnami/postgresql/data as the hostPath.path variable. - David Losert
Sorry, my mistake. I mistook your first config for the Statefulest -_- In that case at least the config seems correct. Are there some default security settings inr your cluster? Have you tried setting the helm charts setting volumePermissions.enabled to true?? - David Losert
it works, thanks a lot - pado
Sure thing. Let me add it as an answer, so people looking into this later see what fixed the problem. - David Losert

1 Answers

5
votes

Try setting the helm charts volumePermissions.enabled to true.

Sometimes the cluster settings don't give the running container enough permissions to actuall write to the mounted volume by default.