mirror of
https://github.com/zalando/postgres-operator.git
synced 2026-09-30 14:47:04 +02:00
Jonathan Juares Beber
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
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