public_git/postgres-operator
1
0
Fork 0
mirror of https://github.com/zalando/postgres-operator.git synced 2026-10-05 09:17:15 +02:00
Code Issues Projects Releases Wiki Activity

merge master

Browse Source
This commit is contained in:
Sergey Dudoladov
2020-04-01 13:48:06 +02:00
parent 63fbab20af b43b22dfcc
commit 1182c17963
35 changed files with 669 additions and 647 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/cluster_manifest.md
+13 -13
View File
@@ -140,10 +140,10 @@ These parameters are grouped directly under the `spec` key in the manifest.
is `false`, then no volume will be mounted no matter how operator was
configured (so you can override the operator configuration). Optional.
* **enableConnectionPool**
Tells the operator to create a connection pool with a database. If this
field is true, a connection pool deployment will be created even if
`connectionPool` section is empty. Optional, not set by default.
* **enableConnectionPooler**
Tells the operator to create a connection pooler with a database. If this
field is true, a connection pooler deployment will be created even if
`connectionPooler` section is empty. Optional, not set by default.
* **enableLogicalBackup**
Determines if the logical backup of this cluster should be taken and uploaded
@@ -365,34 +365,34 @@ CPU and memory limits for the sidecar container.
memory limits for the sidecar container. Optional, overrides the
`default_memory_limits` operator configuration parameter. Optional.
## Connection pool
## Connection pooler
Parameters are grouped under the `connectionPool` top-level key and specify
configuration for connection pool. If this section is not empty, a connection
pool will be created for a database even if `enableConnectionPool` is not
Parameters are grouped under the `connectionPooler` top-level key and specify
configuration for connection pooler. If this section is not empty, a connection
pooler will be created for a database even if `enableConnectionPooler` is not
present.
* **numberOfInstances**
How many instances of connection pool to create.
How many instances of connection pooler to create.
* **schema**
Schema to create for credentials lookup function.
* **user**
User to create for connection pool to be able to connect to a database.
User to create for connection pooler to be able to connect to a database.
* **dockerImage**
Which docker image to use for connection pool deployment.
Which docker image to use for connection pooler deployment.
* **maxDBConnections**
How many connections the pooler can max hold. This value is divided among the
pooler pods.
* **mode**
In which mode to run connection pool, transaction or session.
In which mode to run connection pooler, transaction or session.
* **resources**
Resource configuration for connection pool deployment.
Resource configuration for connection pooler deployment.
## Custom TLS certificates
docs/reference/operator_parameters.md
+18 -18
View File
@@ -601,39 +601,39 @@ scalyr sidecar. In the CRD-based configuration they are grouped under the
* **scalyr_memory_limit**
Memory limit value for the Scalyr sidecar. The default is `500Mi`.
## Connection pool configuration
## Connection pooler configuration
Parameters are grouped under the `connection_pool` top-level key and specify
default configuration for connection pool, if a postgres manifest requests it
Parameters are grouped under the `connection_pooler` top-level key and specify
default configuration for connection pooler, if a postgres manifest requests it
but do not specify some of the parameters. All of them are optional with the
operator being able to provide some reasonable defaults.
* **connection_pool_number_of_instances**
How many instances of connection pool to create. Default is 2 which is also
* **connection_pooler_number_of_instances**
How many instances of connection pooler to create. Default is 2 which is also
the required minimum.
* **connection_pool_schema**
* **connection_pooler_schema**
Schema to create for credentials lookup function. Default is `pooler`.
* **connection_pool_user**
User to create for connection pool to be able to connect to a database.
* **connection_pooler_user**
User to create for connection pooler to be able to connect to a database.
Default is `pooler`.
* **connection_pool_image**
Docker image to use for connection pool deployment.
* **connection_pooler_image**
Docker image to use for connection pooler deployment.
Default: "registry.opensource.zalan.do/acid/pgbouncer"
* **connection_pool_max_db_connections**
* **connection_pooler_max_db_connections**
How many connections the pooler can max hold. This value is divided among the
pooler pods. Default is 60 which will make up 30 connections per pod for the
default setup with two instances.
* **connection_pool_mode**
Default pool mode, `session` or `transaction`. Default is `transaction`.
* **connection_pooler_mode**
Default pooler mode, `session` or `transaction`. Default is `transaction`.
* **connection_pool_default_cpu_request**
**connection_pool_default_memory_reques**
**connection_pool_default_cpu_limit**
**connection_pool_default_memory_limit**
Default resource configuration for connection pool deployment. The internal
* **connection_pooler_default_cpu_request**
**connection_pooler_default_memory_reques**
**connection_pooler_default_cpu_limit**
**connection_pooler_default_memory_limit**
Default resource configuration for connection pooler deployment. The internal
default for memory request and limit is `100Mi`, for CPU it is `500m` and `1`.
docs/user.md
+34 -26
View File
@@ -512,39 +512,38 @@ monitoring is outside the scope of operator responsibilities. See
[administrator documentation](administrator.md) for details on how backups are
executed.
## Connection pool
## Connection pooler
The operator can create a database side connection pool for those applications,
where an application side pool is not feasible, but a number of connections is
high. To create a connection pool together with a database, modify the
The operator can create a database side connection pooler for those applications
where an application side pooler is not feasible, but a number of connections is
high. To create a connection pooler together with a database, modify the
manifest:
```yaml
spec:
enableConnectionPool: true
enableConnectionPooler: true
```
This will tell the operator to create a connection pool with default
This will tell the operator to create a connection pooler with default
configuration, through which one can access the master via a separate service
`{cluster-name}-pooler`. In most of the cases provided default configuration
should be good enough.
To configure a new connection pool, specify:
`{cluster-name}-pooler`. In most of the cases the
[default configuration](reference/operator_parameters.md#connection-pool-configuration)
should be good enough. To configure a new connection pooler individually for
each Postgres cluster, specify:
```
spec:
connectionPool:
# how many instances of connection pool to create
number_of_instances: 2
connectionPooler:
# how many instances of connection pooler to create
numberOfInstances: 2
# in which mode to run, session or transaction
mode: "transaction"
# schema, which operator will create to install credentials lookup
# function
# schema, which operator will create to install credentials lookup function
schema: "pooler"
# user, which operator will create for connection pool
# user, which operator will create for connection pooler
user: "pooler"
# resources for each instance
@@ -557,13 +556,17 @@ spec:
memory: 100Mi
```
By default `pgbouncer` is used to create a connection pool. To find out about
pool modes see [docs](https://www.pgbouncer.org/config.html#pool_mode) (but it
should be general approach between different implementation).
The `enableConnectionPooler` flag is not required when the `connectionPooler`
section is present in the manifest. But, it can be used to disable/remove the
pooler while keeping its configuration.
Note, that using `pgbouncer` means meaningful resource CPU limit should be less
than 1 core (there is a way to utilize more than one, but in K8S it's easier
just to spin up more instances).
By default, `pgbouncer` is used as connection pooler. To find out about pooler
modes read the `pgbouncer` [docs](https://www.pgbouncer.org/config.html#pooler_mode)
(but it should be the general approach between different implementation).
Note, that using `pgbouncer` a meaningful resource CPU limit should be 1 core
or less (there is a way to utilize more than one, but in K8s it's easier just to
spin up more instances).
## Custom TLS certificates
@@ -572,10 +575,15 @@ However, this certificate cannot be verified and thus doesn't protect from
active MITM attacks. In this section we show how to specify a custom TLS
certificate which is mounted in the database pods via a K8s Secret.
Before applying these changes, the operator must also be configured with the
`spilo_fsgroup` set to the GID matching the postgres user group. If the value
is not provided, the cluster will default to `103` which is the GID from the
default spilo image.
Before applying these changes, in k8s the operator must also be configured with
the `spilo_fsgroup` set to the GID matching the postgres user group. If you
don't know the value, use `103` which is the GID from the default spilo image
(`spilo_fsgroup=103` in the cluster request spec).
OpenShift allocates the users and groups dynamically (based on scc), and their
range is different in every namespace. Due to this dynamic behaviour, it's not
trivial to know at deploy time the uid/gid of the user in the cluster.
This way, in OpenShift, you may want to skip the spilo_fsgroup setting.
Upload the cert as a kubernetes secret:
```sh