clusterdatabase-as-a-servicedata-infrastructuregolangkubernetesmanaged-servicesoperatorpostgrespostgres-operatorpostgresql
9dfa433363
Connection pooler support Add support for a connection pooler. The idea is to make it generic enough to be able to switch between different implementations (e.g. pgbouncer or odyssey). Operator needs to create a deployment with pooler and a service for it to access. For connection pool to work properly, a database needs to be prepared by operator, namely a separate user have to be created with an access to an installed lookup function (to fetch credential for other users). This setups is supposed to be used only by robot/application users. Usually a connection pool implementation is more CPU bounded, so it makes sense to create several pods for connection pool with more emphasize on cpu resources. At the moment there are no special affinity or tolerations assigned to bring those pods closer to the database. For availability purposes minimal number of connection pool pods is 2, ideally they have to be distributed between different nodes/AZ, but it's not enforced in the operator itself. Available configuration supposed to be ergonomic and in the normal case require minimum changes to a manifest to enable connection pool. To have more control over the configuration and functionality on the pool side one can customize the corresponding docker image. Co-authored-by: Felix Kunde <felix-kunde@gmx.de> |
||
|---|---|---|
| charts | ||
| cmd | ||
| docker | ||
| docs | ||
| e2e | ||
| hack | ||
| kubectl-pg | ||
| manifests | ||
| pkg | ||
| ui | ||
| .flake8 | ||
| .gitignore | ||
| .golangci.yml | ||
| .travis.yml | ||
| .zappr.yaml | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| MAINTAINERS | ||
| Makefile | ||
| README.md | ||
| SECURITY.md | ||
| build-ci.sh | ||
| delivery.yaml | ||
| go.mod | ||
| go.sum | ||
| mkdocs.yml | ||
| run_operator_locally.sh | ||
README.md
Postgres Operator
The Postgres Operator enables highly-available PostgreSQL clusters on Kubernetes (K8s) powered by Patroni. It is configured only through manifests to ease integration into automated CI/CD pipelines with no access to Kubernetes directly.
Operator features
- Rolling updates on Postgres cluster changes
- Volume resize without Pod restarts
- Cloning Postgres clusters
- Logical Backups to S3 Bucket
- Standby cluster from S3 WAL archive
- Configurable for non-cloud environments
- UI to create and edit Postgres cluster manifests
PostgreSQL features
- Supports PostgreSQL 9.6+
- Streaming replication cluster via Patroni
- Point-In-Time-Recovery with pg_basebackup / WAL-E via Spilo
- Preload libraries: bg_mon, pg_stat_statements, pgextwlist, pg_auth_mon
- Incl. popular Postgres extensions such as decoderbufs, hypopg, pg_cron, pg_partman, pg_stat_kcache, pgq, plpgsql_check, postgis, set_user and timescaledb
The Postgres Operator has been developed at Zalando and is being used in production for over two years.
Getting started
For a quick first impression follow the instructions of this tutorial.
Documentation
There is a browser-friendly version of this documentation at postgres-operator.readthedocs.io
- How it works
- Installation
- The Postgres experience on K8s
- The Postgres Operator UI
- DBA options - from RBAC to backup
- Build, debug and extend the operator
- Configuration options
- Postgres manifest reference
- Command-line options and environment variables
Google Summer of Code
The Postgres Operator made it to the Google Summer of Code 2019! Check our ideas and start discussions in the issue tracker.
Community
There are two places to get in touch with the community:
- The GitHub issue tracker
- The #postgres-operator slack channel