ba60e15d07
The [operator parameters][1] already support the `custom_service_annotations` config.With this parameter is possible to define custom annotations that will be used on the services created by the operator. The `custom_service_annotations` as all the other [operator parameters][1] are defined on the operator level and do not allow customization on the cluster level. A cluster may require different service annotations, as for example, set up different cloud load balancers timeouts, different ingress annotations, and/or enable more customizable environments. This commit introduces a new parameter on the cluster level, called `serviceAnnotations`, responsible for defining custom annotations just for the services created by the operator to the specifically defined cluster. It allows a mix of configuration between `custom_service_annotations` and `serviceAnnotations` where the latest one will have priority. In order to allow custom service annotations to be used on services without LoadBalancers (as for example, service mesh services annotations) both `custom_service_annotations` and `serviceAnnotations` are applied independently of load-balancing configuration. For retro-compatibility purposes, `custom_service_annotations` is still under [Load balancer related options][2]. The two default annotations when using LoadBalancer services, `external-dns.alpha.kubernetes.io/hostname` and `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout` are still defined by the operator. `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout` can be overridden by `custom_service_annotations` or `serviceAnnotations`, allowing a more customizable environment. `external-dns.alpha.kubernetes.io/hostname` can not be overridden once there is no differentiation between custom service annotations for replicas and masters. It updates the documentation and creates the necessary unit and e2e tests to the above-described feature too. [1]: https://github.com/zalando/postgres-operator/blob/master/docs/reference/operator_parameters.md [2]: https://github.com/zalando/postgres-operator/blob/master/docs/reference/operator_parameters.md#load-balancer-related-options |
||
|---|---|---|
| .. | ||
| 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