-
Notifications
You must be signed in to change notification settings - Fork 9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No volume created after helm chart install results in pending pod #24628
Comments
It seems an issue with the PVs in the nodes/cluster and not something related to the Helm chart itself. Having said that, if you think that's not the case and are interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here. Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance. If you have any questions about the application itself, customizing its content, or questions about technology and infrastructure usage, we highly recommend that you refer to the forums and user guides provided by the project responsible for the application or technology. With that said, we'll keep this ticket open until the stale bot automatically closes it, in case someone from the community contributes valuable insights. |
OK, maybe this is a documentation issue? When reading the README.md I expected that installing the helm chart should be sufficient to run the database. It looks like the pod is expecting a PV. Should the README.md contain a hint about the needed volume or a link to another documentation ? |
Just for others trying to run this chart for the first time. You need to create the PVs before something is able to start. Change the following yaml to fit your needs and the Pods will start. apiVersion: v1
kind: PersistentVolume
metadata:
labels:
synaptic-part: pgdata
name: data-pgdata-postgresql-ha-postgresql-0
annotations:
pv.beta.kubernetes.io/gid: "1008"
spec:
storageClassName: ""
capacity:
storage: 8Gi
accessModes:
- ReadWriteOnce
nfs:
path: /exports/data0
server: nfs.acme.com
readOnly: false
---
apiVersion: v1
kind: PersistentVolume
metadata:
labels:
synaptic-part: pgdata
name: data-pgdata-postgresql-ha-postgresql-1
annotations:
pv.beta.kubernetes.io/gid: "1008"
spec:
storageClassName: ""
capacity:
storage: 8Gi
accessModes:
- ReadWriteOnce
nfs:
path: /exports/data1
server: nfs.acme.com
readOnly: false
---
apiVersion: v1
kind: PersistentVolume
metadata:
labels:
synaptic-part: pgdata
name: data-pgdata-postgresql-ha-postgresql-2
annotations:
pv.beta.kubernetes.io/gid: "1008"
spec:
storageClassName: ""
capacity:
storage: 8Gi
accessModes:
- ReadWriteOnce
nfs:
path: /exports/data2
server: nfs.acme.com
readOnly: false
---
|
mmm I am not able to see why this is needed in your case, but the Helm chart should work fine out of the box. |
When I create the volumes before installing the chart the pods start up after a while. If no volume was created, the pods stay in Pending state. |
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback. |
Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary. |
Name and Version
Bitname/postgresql 15.1.2
What architecture are you using?
amd64
What steps will reproduce the bug?
I just used this command as listed in GitHub:
helm install my-release oci://registry-1.docker.io/bitnamicharts/postgresql
What is the expected behavior?
I expected that the pod would come up in status Running.
What do you see instead?
The pod stocks in status PENDING.
Additional information
The cluster has 3 nodes. Version of Kubernetes is 1.28.2, Debian Bookworm, Helm version 3.14.2.
kubectl describe pod my-release:
kubectl get PVC:
kubectl get pv:
As I understand the GitHub page the used command should be sufficient to spin up the postgres db.
The text was updated successfully, but these errors were encountered: