Zalando's DBaaS team has just released a new version of their Postgres Operator for Kubernetes. It now offers support for pgBouncer connection pooler which is beneficial when your app is scaled out to many pods, all holding connections. The pgBouncer deployment can simply be enabled in the Postgres cluster manifest and will help keeping connection count low and throughput high in such scenarios.
Databases can now be created with default (owner, reader, writer) roles and privileges to ease the setup for our users. It's also possible to specify database schemas and extensions in manifest to bootstrap.
New controller annotations can be used to run multiple operators next to each other without interfering. With this you can also easily detach a cluster from the control of the operator. Annotations injected to the Postgres resource can now be propagated to the StatefulSet i.e. to trigger downscaling of test clusters during quiet hours.
Our community is getting stronger. We receive valuable feedback and see increased activity of users providing more complex pull requests. This release in particular contains many feature highlights from external contributions:
sidecars to ease the integration with e.g. monitoring / logging solutions.Postgresql resource to provide better feedback to the userAs always, the Postgres Operator is shipped with the latest Patroni and Spilo releases. Rolling updates of the docker image now check the health of all replicas and can be executed in lazy fashion until the next node rotation to reduce downtime.
Zalando is running several hundreds of Postgres clusters on top of Kubernetes via the operator and numbers keep growing steadily. Thanks to everyone involved, reporting bugs, suggesting improvements and contributing to the Postgres Operator!