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> |
||
|---|---|---|
| .. | ||
| tests | ||
| Dockerfile | ||
| Makefile | ||
| README.md | ||
| kind-cluster-postgres-operator-e2e-tests.yaml | ||
| requirements.txt | ||
| run.sh | ||
README.md
Postgres Operator end-to-end tests
End-to-end tests shall ensure that the Postgres Operator does its job when
applying manifests against a Kubernetes (K8s) environment. A test runner
Dockerfile is provided to run e2e tests without the need to install K8s and
its runtime kubectl in advance. The test runner uses
kind to create a local K8s cluster which runs on
Docker.
Prerequisites
Docker Go
Build test runner
In the directory of the cloned Postgres Operator repository change to the e2e folder and run:
make
This will build the postgres-operator-e2e-tests image and download the kind
runtime.
Run tests
In the e2e folder you can invoke tests either with make test or with:
./run.sh
To run both the build and test step you can invoke make e2e from the parent
directory.
Covered use cases
The current tests are all bundled in test_e2e.py:
- support for multiple namespaces
- scale Postgres cluster up and down
- taint-based eviction of Postgres pods
- invoking logical backup cron job
- uniqueness of master pod
- custom service annotations