zalando / zalando/postgres-operator
Protecting pooler pods
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 5.2k
- Forks
- 1.1k
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 3
Description
Using operator registry.opensource.zalan.do/acid/postgres-operator:v1.9.0 on a cloud k8s I noticed that the podPriorityClassName value from postgresql manifests is only applied to the actual database pods, not to the poolers. Also, there is no PodDisruptionBudget created for the poolers. Last night we had the situation that the poolers got rescheduled several times resulting in failing nightly jobs because of missing database connectivity. Did I miss a setting in the configuration? What is the best practice for protecting the pooler pods to ensure database availability? Or is this a missing feature?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review how the operator handles podPriorityClassName and generates pooler resources for PostgreSQL clusters. Determine whether poolers can receive the priority class and a PodDisruptionBudget; done means the configuration protects pooler availability during Kubernetes rescheduling.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes, postgresql
- Domain
- databases, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 28/100