public_git/postgres-operator
1
0
Fork 0
mirror of https://github.com/zalando/postgres-operator.git synced 2026-09-30 22:46:52 +02:00
Code Issues Projects Releases Wiki Activity

Update docs for v1.2 (#609)

Browse Source 
* update docs and move parts from README to index.md
* fix typos, headings and code alignment in docs
This commit is contained in:
Felix Kunde
2019-07-11 17:19:27 +02:00
committed by GitHub
parent 1c340c68c6
commit 4fc5822b24
17 changed files with 689 additions and 618 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/cluster_manifest.md
+76 -65
View File
@@ -1,10 +1,12 @@
Individual postgres clusters are described by the Kubernetes *cluster manifest*
that has the structure defined by the `postgres CRD` (custom resource
# Cluster manifest reference
Individual Postgres clusters are described by the Kubernetes *cluster manifest*
that has the structure defined by the `postgresql` CRD (custom resource
definition). The following section describes the structure of the manifest and
the purpose of individual keys. You can take a look at the examples of the
[minimal](https://github.com/zalando/postgres-operator/blob/master/manifests/minimal-postgres-manifest.yaml)
[minimal](../manifests/minimal-postgres-manifest.yaml)
and the
[complete](https://github.com/zalando/postgres-operator/blob/master/manifests/complete-postgres-manifest.yaml)
[complete](../manifests/complete-postgres-manifest.yaml)
cluster manifests.
When Kubernetes resources, such as memory, CPU or volumes, are configured,
@@ -19,7 +21,7 @@ applied.
## Manifest structure
A postgres manifest is a `YAML` document. On the top level both individual
A Postgres manifest is a `YAML` document. On the top level both individual
parameters and parameter groups can be defined. Parameter names are written
in camelCase.
@@ -54,26 +56,31 @@ These parameters are grouped directly under the `spec` key in the manifest.
name of the team the cluster belongs to. Changing it after the cluster
creation is not supported. Required field.
* **numberOfInstances**
total number of instances for a given cluster. The operator parameters
`max_instances` and `min_instances` may also adjust this number. Required
field.
* **dockerImage**
custom docker image that overrides the **docker_image** operator parameter.
It should be a [Spilo](https://github.com/zalando/spilo) image. Optional.
It should be a [Spilo](https://github.com/zalando/spilo) image. Optional.
* **spiloFSGroup**
the Persistent Volumes for the spilo pods in the StatefulSet will be owned
and writable by the group ID specified. This will override the **spilo_fsgroup**
the Persistent Volumes for the Spilo pods in the StatefulSet will be owned and
writable by the group ID specified. This will override the **spilo_fsgroup**
operator parameter. This is required to run Spilo as a non-root process, but
requires a custom spilo image. Note the FSGroup of a Pod cannot be changed
without recreating a new Pod.
requires a custom Spilo image. Note the FSGroup of a Pod cannot be changed
without recreating a new Pod. Optional.
* **enableMasterLoadBalancer**
boolean flag to override the operator defaults (set by the
`enable_master_load_balancer` parameter) to define whether to enable the load
balancer pointing to the postgres primary. Optional.
balancer pointing to the Postgres primary. Optional.
* **enableReplicaLoadBalancer**
boolean flag to override the operator defaults (set by the
`enable_replica_load_balancer` parameter) to define whether to enable the
load balancer pointing to the postgres standby instances. Optional.
load balancer pointing to the Postgres standby instances. Optional.
* **allowedSourceRanges**
when one or more load balancers are enabled for the cluster, this parameter
@@ -82,11 +89,6 @@ These parameters are grouped directly under the `spec` key in the manifest.
this parameter. Optional, when empty the load balancer service becomes
inaccessible from outside of the Kubernetes cluster.
* **numberOfInstances**
total number of instances for a given cluster. The operator parameters
`max_instances` and `min_instances` may also adjust this number. Required
field.
* **users**
a map of usernames to user flags for the users that should be created in the
cluster by the operator. User flags are a list, allowed elements are
@@ -114,7 +116,7 @@ These parameters are grouped directly under the `spec` key in the manifest.
that should be assigned to the cluster pods. When not specified, the value
is taken from the `pod_priority_class_name` operator parameter, if not set
then the default priority class is taken. The priority class itself must be
defined in advance.
defined in advance. Optional.
* **enableShmVolume**
Start a database pod without limitations on shm memory. By default docker
@@ -126,35 +128,36 @@ These parameters are grouped directly under the `spec` key in the manifest.
about mounting a volume will be made based on operator configuration
(`enable_shm_volume`, which is `true` by default). It it's present and value
is `false`, then no volume will be mounted no matter how operator was
configured (so you can override the operator configuration).
configured (so you can override the operator configuration). Optional.
* **enableLogicalBackup**
Determines if the logical backup of this cluster should be taken and uploaded
to S3. Default: false.
to S3. Default: false. Optional.
* **logicalBackupSchedule**
Schedule for the logical backup k8s cron job. Please take [the reference schedule format](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#schedule)
into account. Default: "30 00 \* \* \*"
Schedule for the logical backup k8s cron job. Please take
[the reference schedule format](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#schedule)
into account. Optional. Default is: "30 00 \* \* \*"
## Postgres parameters
Those parameters are grouped under the `postgresql` top-level key.
Those parameters are grouped under the `postgresql` top-level key, which is
required in the manifest.
* **version**
the postgres major version of the cluster. Looks at the [Spilo
the Postgres major version of the cluster. Looks at the [Spilo
project](https://github.com/zalando/spilo/releases) for the list of supported
versions. Changing the cluster version once the cluster has been bootstrapped
is not supported. Required field.
* **parameters**
a dictionary of postgres parameter names and values to apply to the resulting
cluster. Optional (Spilo automatically sets reasonable defaults for
parameters like work_mem or max_connections).
a dictionary of Postgres parameter names and values to apply to the resulting
cluster. Optional (Spilo automatically sets reasonable defaults for parameters
like `work_mem` or `max_connections`).
## Patroni parameters
Those parameters are grouped under the `patroni` top-level key. See the [patroni
Those parameters are grouped under the `patroni` top-level key. See the [Patroni
documentation](https://patroni.readthedocs.io/en/latest/SETTINGS.html) for the
explanation of `ttl` and `loop_wait` parameters.
@@ -176,19 +179,19 @@ explanation of `ttl` and `loop_wait` parameters.
authentication. Optional.
* **ttl**
patroni `ttl` parameter value, optional. The default is set by the Spilo
Patroni `ttl` parameter value, optional. The default is set by the Spilo
docker image. Optional.
* **loop_wait**
patroni `loop_wait` parameter value, optional. The default is set by the
Patroni `loop_wait` parameter value, optional. The default is set by the
Spilo docker image. Optional.
* **retry_timeout**
patroni `retry_timeout` parameter value, optional. The default is set by the
Patroni `retry_timeout` parameter value, optional. The default is set by the
Spilo docker image. Optional.
* **maximum_lag_on_failover**
patroni `maximum_lag_on_failover` parameter value, optional. The default is
Patroni `maximum_lag_on_failover` parameter value, optional. The default is
set by the Spilo docker image. Optional.
* **slots**
@@ -199,38 +202,34 @@ explanation of `ttl` and `loop_wait` parameters.
automatically created by Patroni for cluster members and permanent replication
slots. Optional.
* **standby**
initializes cluster as a standby creating a cascading replication, where standby leader is streaming from specified remote location
## Postgres container resources
Those parameters define [CPU and memory requests and
limits](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)
for the postgres container. They are grouped under the `resources` top-level
key. There are two subgroups, `requests` and `limits`.
Those parameters define [CPU and memory requests and limits](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)
for the Postgres container. They are grouped under the `resources` top-level
key with subgroups `requests` and `limits`.
### Requests
CPU and memory requests for the postgres container.
CPU and memory requests for the Postgres container.
* **cpu**
CPU requests for the postgres container. Optional, overrides the
CPU requests for the Postgres container. Optional, overrides the
`default_cpu_requests` operator configuration parameter. Optional.
* **memory**
memory requests for the postgres container. Optional, overrides the
memory requests for the Postgres container. Optional, overrides the
`default_memory_request` operator configuration parameter. Optional.
#### Limits
### Limits
CPU and memory limits for the postgres container.
CPU and memory limits for the Postgres container.
* **cpu**
CPU limits for the postgres container. Optional, overrides the
CPU limits for the Postgres container. Optional, overrides the
`default_cpu_limits` operator configuration parameter. Optional.
* **memory**
memory limits for the postgres container. Optional, overrides the
memory limits for the Postgres container. Optional, overrides the
`default_memory_limits` operator configuration parameter. Optional.
## Parameters defining how to clone the cluster from another one
@@ -257,8 +256,13 @@ under the `clone` top-level key and do not affect the already running cluster.
timestamp. When this parameter is set the operator will not consider cloning
from the live cluster, even if it is running, and instead goes to S3. Optional.
* **s3_wal_path**
the url to S3 bucket containing the WAL archive of the cluster to be cloned.
Optional.
* **s3_endpoint**
the url of the S3-compatible service should be set when cloning from non AWS S3. Optional.
the url of the S3-compatible service should be set when cloning from non AWS
S3. Optional.
* **s3_access_key_id**
the access key id, used for authentication on S3 service. Optional.
@@ -267,13 +271,25 @@ under the `clone` top-level key and do not affect the already running cluster.
the secret access key, used for authentication on S3 service. Optional.
* **s3_force_path_style**
to enable path-style addressing(i.e., http://s3.amazonaws.com/BUCKET/KEY) when connecting to an S3-compatible service
that lack of support for sub-domain style bucket URLs (i.e., http://BUCKET.s3.amazonaws.com/KEY). Optional.
to enable path-style addressing(i.e., http://s3.amazonaws.com/BUCKET/KEY)
when connecting to an S3-compatible service that lack of support for
sub-domain style bucket URLs (i.e., http://BUCKET.s3.amazonaws.com/KEY).
Optional.
### EBS volume resizing
## Standby cluster
On startup, an existing `standby` top-level key creates a standby Postgres
cluster streaming from a remote location. So far only streaming from a S3 WAL
archive is supported.
* **s3_wal_path**
the url to S3 bucket containing the WAL archive of the remote primary.
Required when the `standby` section is present.
## EBS volume resizing
Those parameters are grouped under the `volume` top-level key and define the
properties of the persistent storage that stores postgres data.
properties of the persistent storage that stores Postgres data.
* **size**
the size of the target EBS volume. Usual Kubernetes size modifiers, i.e. `Gi`
@@ -286,13 +302,13 @@ properties of the persistent storage that stores postgres data.
for the details on storage classes. Optional.
* **subPath**
Subpath to use when mounting volume into Spilo container
Subpath to use when mounting volume into Spilo container. Optional.
### Sidecar definitions
## Sidecar definitions
Those parameters are defined under the `sidecars` key. They consist of a list
of dictionaries, each defining one sidecar (an extra container running
along the main postgres container on the same pod). The following keys can be
along the main Postgres container on the same pod). The following keys can be
defined in the sidecar dictionary:
* **name**
@@ -306,16 +322,11 @@ defined in the sidecar dictionary:
(https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)
for environment variables. Optional.
* **resources** see below. Optional.
* **resources**
[CPU and memory requests and limits](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container)
for each sidecar container. Optional.
#### Sidecar container resources
Those parameters define [CPU and memory requests and
limits](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)
for the sidecar container. They are grouped under the `resources` key for each sidecar.
There are two subgroups, `requests` and `limits`.
##### Requests
### Requests
CPU and memory requests for the sidecar container.
@@ -327,7 +338,7 @@ CPU and memory requests for the sidecar container.
memory requests for the sidecar container. Optional, overrides the
`default_memory_request` operator configuration parameter. Optional.
##### Limits
### Limits
CPU and memory limits for the sidecar container.
docs/reference/command_line_and_environment.md
+3 -3
View File
@@ -50,9 +50,9 @@ The following environment variables are accepted by the operator:
`scalyr_api_key` operator parameter.
* **CRD_READY_WAIT_TIMEOUT**
defines the timeout for the complete postgres CRD creation. When not set
defines the timeout for the complete `postgresql` CRD creation. When not set
default is 30s.
* **CRD_READY_WAIT_INTERVAL**
defines the interval between consecutive attempts waiting for the postgres
CRD to be created. The default is 5s.
defines the interval between consecutive attempts waiting for the
`postgresql` CRD to be created. The default is 5s.
docs/reference/operator_parameters.md
+60 -57
View File
@@ -1,3 +1,5 @@
# Configuration parameters
There are two mutually-exclusive methods to set the Postgres Operator
configuration.
@@ -8,12 +10,12 @@ configuration.
maps. String values containing ':' should be enclosed in quotes. The
configuration is flat, parameter group names below are not reflected in the
configuration structure. There is an
[example](https://github.com/zalando/postgres-operator/blob/master/manifests/configmap.yaml)
[example](../manifests/configmap.yaml)
* CRD-based configuration. The configuration is stored in a custom YAML
manifest. The manifest is an instance of the custom resource definition (CRD)
called `OperatorConfiguration`. The operator registers this CRD during the
start and uses it for configuration if the [operator deployment manifest ](https://github.com/zalando/postgres-operator/blob/master/manifests/postgres-operator.yaml#L21)
start and uses it for configuration if the [operator deployment manifest](../manifests/postgres-operator.yaml#L36)
sets the `POSTGRES_OPERATOR_CONFIGURATION_OBJECT` env variable to a non-empty
value. The variable should point to the `postgresql-operator-configuration`
object in the operator's namespace.
@@ -22,7 +24,7 @@ configuration.
simply represented in the usual YAML way. There are no default values built-in
in the operator, each parameter that is not supplied in the configuration
receives an empty value. In order to create your own configuration just copy
the [default one](https://github.com/zalando/postgres-operator/blob/master/manifests/postgresql-operator-default-configuration.yaml)
the [default one](../manifests/postgresql-operator-default-configuration.yaml)
and change it.
To test the CRD-based configuration locally, use the following
@@ -32,10 +34,10 @@ configuration.
kubectl create -f manifests/postgresql-operator-default-configuration.yaml
kubectl get operatorconfigurations postgresql-operator-default-configuration -o yaml
```
Note that the operator first attempts to register the CRD of the `OperatorConfiguration`
and then waits for an instance to be created. In between these two event the
operator pod may be failing since it cannot fetch the not-yet-existing
`OperatorConfiguration` instance.
Note that the operator first attempts to register the CRD of the
`OperatorConfiguration` and then waits for an instance to be created. In
between these two event the operator pod may be failing since it cannot fetch
the not-yet-existing `OperatorConfiguration` instance.
The CRD-based configuration is more powerful than the one based on ConfigMaps
and should be used unless there is a compatibility requirement to use an already
@@ -56,11 +58,11 @@ parameters, those parameters have no effect and are replaced by the
`CRD_READY_WAIT_INTERVAL` and `CRD_READY_WAIT_TIMEOUT` environment variables.
They will be deprecated and removed in the future.
For the configmap operator configuration, the [default parameter values](https://github.com/zalando-incubator/postgres-operator/blob/master/pkg/util/config/config.go#L14)
For the configmap configuration, the [default parameter values](../pkg/util/config/config.go#L14)
mentioned here are likely to be overwritten in your local operator installation
via your local version of the operator configmap. In the case you use the
operator CRD, all the CRD defaults are provided in the
[operator's default configuration manifest](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/postgresql-operator-default-configuration.yaml)
[operator's default configuration manifest](../manifests/postgresql-operator-default-configuration.yaml)
Variable names are underscore-separated words.
@@ -75,7 +77,7 @@ Those are top-level keys, containing both leaf keys and groups.
Kubernetes-native DCS).
* **docker_image**
Spilo docker image for postgres instances. For production, don't rely on the
Spilo docker image for Postgres instances. For production, don't rely on the
default image, as it might be not the most up-to-date one. Instead, build
your own Spilo image from the [github
repository](https://github.com/zalando/spilo).
@@ -98,12 +100,12 @@ Those are top-level keys, containing both leaf keys and groups.
create/update/delete/sync clusters concurrently. The default is `4`.
* **max_instances**
operator will cap the number of instances in any managed postgres cluster up
operator will cap the number of instances in any managed Postgres cluster up
to the value of this parameter. When `-1` is specified, no limits are applied.
The default is `-1`.
* **min_instances**
operator will run at least the number of instances for any given postgres
operator will run at least the number of instances for any given Postgres
cluster equal to the value of this parameter. When `-1` is specified, no
limits are applied. The default is `-1`.
@@ -120,7 +122,7 @@ Those are top-level keys, containing both leaf keys and groups.
containers with high memory limits due to the lack of memory on Kubernetes
cluster nodes. This affects all containers created by the operator (Postgres,
Scalyr sidecar, and other sidecars); to set resources for the operator's own
container, change the [operator deployment manually](https://github.com/zalando/postgres-operator/blob/master/manifests/postgres-operator.yaml#L13).
container, change the [operator deployment manually](../manifests/postgres-operator.yaml#L20).
The default is `false`.
## Postgres users
@@ -129,11 +131,11 @@ Parameters describing Postgres users. In a CRD-configuration, they are grouped
under the `users` key.
* **super_username**
postgres `superuser` name to be created by `initdb`. The default is
Postgres `superuser` name to be created by `initdb`. The default is
`postgres`.
* **replication_username**
postgres username used for replication between instances. The default is
Postgres username used for replication between instances. The default is
`standby`.
## Kubernetes resources
@@ -158,17 +160,16 @@ configuration they are grouped under the `kubernetes` key.
This definition must bind pod service account to a role with permission
sufficient for the pods to start and for Patroni to access k8s endpoints;
service account on its own lacks any such rights starting with k8s v1.8. If
not excplicitly defined by the user, a simple definition that binds the
not explicitly defined by the user, a simple definition that binds the
account to the operator's own 'zalando-postgres-operator' cluster role will
be used. The default is empty.
* **pod_terminate_grace_period**
Postgres pods are [terminated
forcefully](https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods)
Postgres pods are [terminated forcefully](https://kubernetes.io/docs/concepts/workloads/pods/pod/#termination-of-pods)
after this timeout. The default is `5m`.
* **watched_namespace**
The operator watches for postgres objects in the given namespace. If not
The operator watches for Postgres objects in the given namespace. If not
specified, the value is taken from the operator namespace. A special `*`
value makes it watch all namespaces. The default is empty (watch the operator
pod namespace).
@@ -195,9 +196,9 @@ configuration they are grouped under the `kubernetes` key.
`{username}.{cluster}.credentials.{tprkind}.{tprgroup}`.
* **cluster_domain**
defines the default dns domain for the kubernetes cluster the operator is
defines the default DNS domain for the kubernetes cluster the operator is
running in. The default is `cluster.local`. Used by the operator to connect
to the postgres clusters after creation.
to the Postgres clusters after creation.
* **oauth_token_secret_name**
a name of the secret containing the `OAuth2` token to pass to the teams API.
@@ -217,9 +218,8 @@ configuration they are grouped under the `kubernetes` key.
* **inherited_labels**
list of labels that can be inherited from the cluster manifest, and added to
each child objects (`StatefulSet`, `Pod`, `Service` and `Endpoints`) created
by the opertor.
Typical use case is to dynamically pass labels that are specific to a given
postgres cluster, in order to implement `NetworkPolicy`.
by the operator. Typical use case is to dynamically pass labels that are
specific to a given Postgres cluster, in order to implement `NetworkPolicy`.
The default is empty.
* **cluster_name_label**
@@ -243,7 +243,7 @@ configuration they are grouped under the `kubernetes` key.
* **pod_environment_configmap**
a name of the ConfigMap with environment variables to populate on every pod.
Right now this ConfigMap is searched in the namespace of the postgres cluster.
Right now this ConfigMap is searched in the namespace of the Postgres cluster.
All variables from that ConfigMap are injected to the pod's environment, on
conflicts they are overridden by the environment variables generated by the
operator. The default is empty.
@@ -254,8 +254,9 @@ configuration they are grouped under the `kubernetes` key.
be defined in advance. Default is empty (use the default priority class).
* **spilo_fsgroup**
the Persistent Volumes for the spilo pods in the StatefulSet will be owned and writable by the group ID specified.
This is required to run Spilo as a non-root process, but requires a custom spilo image. Note the FSGroup of a Pod
the Persistent Volumes for the Spilo pods in the StatefulSet will be owned and
writable by the group ID specified. This is required to run Spilo as a
non-root process, but requires a custom Spilo image. Note the FSGroup of a Pod
cannot be changed without recreating a new Pod.
* **spilo_privileged**
@@ -291,19 +292,19 @@ Those parameters are grouped under the `postgres_pod_resources` key in a
CRD-based configuration.
* **default_cpu_request**
CPU request value for the postgres containers, unless overridden by
CPU request value for the Postgres containers, unless overridden by
cluster-specific settings. The default is `100m`.
* **default_memory_request**
memory request value for the postgres containers, unless overridden by
memory request value for the Postgres containers, unless overridden by
cluster-specific settings. The default is `100Mi`.
* **default_cpu_limit**
CPU limits for the postgres containers, unless overridden by cluster-specific
CPU limits for the Postgres containers, unless overridden by cluster-specific
settings. The default is `3`.
* **default_memory_limit**
memory limits for the postgres containers, unless overridden by cluster-specific
memory limits for the Postgres containers, unless overridden by cluster-specific
settings. The default is `1Gi`.
## Operator timeouts
@@ -334,11 +335,11 @@ CRD-based configuration.
cluster or recreating pods. The default is `10m`.
* **ready_wait_interval**
the interval between consecutive attempts waiting for the postgres CRD to be
created. The default is `5s`.
the interval between consecutive attempts waiting for the `postgresql` CRD to
be created. The default is `5s`.
* **ready_wait_timeout**
the timeout for the complete postgres CRD creation. The default is `30s`.
the timeout for the complete `postgresql` CRD creation. The default is `30s`.
## Load balancer related options
@@ -394,7 +395,7 @@ yet officially supported.
Spilo are S3 and GCS. The default is empty.
* **log_s3_bucket**
S3 bucket to use for shipping postgres daily logs. Works only with S3 on AWS.
S3 bucket to use for shipping Postgres daily logs. Works only with S3 on AWS.
The bucket has to be present and accessible by Postgres pods. The default is
empty.
@@ -413,6 +414,28 @@ yet officially supported.
* **additional_secret_mount_path**
Path to mount the above Secret in the filesystem of the container(s). The default is empty.
## Logical backup
These parameters configure a k8s cron job managed by the operator to produce
Postgres logical backups. In the CRD-based configuration those parameters are
grouped under the `logical_backup` key.
* **logical_backup_schedule**
Backup schedule in the cron format. Please take the
[reference schedule format](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#schedule)
into account. Default: "30 00 \* \* \*"
* **logical_backup_docker_image**
An image for pods of the logical backup job. The [example image](../../docker/logical-backup/Dockerfile)
runs `pg_dumpall` on a replica if possible and uploads compressed results to
an S3 bucket under the key `/spilo/pg_cluster_name/cluster_k8s_uuid/logical_backups`.
The default image is the same image built with the Zalando-internal CI
pipeline. Default: "registry.opensource.zalan.do/acid/logical-backup"
* **logical_backup_s3_bucket**
S3 bucket to store backup results. The bucket has to be present and
accessible by Postgres pods. Default: empty.
## Debugging the operator
Options to aid debugging of the operator itself. Grouped under the `debug` key.
@@ -423,7 +446,7 @@ Options to aid debugging of the operator itself. Grouped under the `debug` key.
* **enable_database_access**
boolean parameter that toggles the functionality of the operator that require
access to the postgres database, i.e. creating databases and users. The
access to the Postgres database, i.e. creating databases and users. The
default is `true`.
## Automatic creation of human users in the database
@@ -442,7 +465,7 @@ key.
`https://teams.example.com/api/`.
* **team_api_role_configuration**
postgres parameters to apply to each team member role. The default is
Postgres parameters to apply to each team member role. The default is
'*log_statement:all*'. It is possible to supply multiple options, separating
them by commas. Options containing commas within the value are not supported,
with the exception of the `search_path`. For instance:
@@ -527,23 +550,3 @@ 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 `1Gi`.
## Logical backup
These parameters configure a k8s cron job managed by the operator to produce
Postgres logical backups. In the CRD-based configuration those parameters are
grouped under the `logical_backup` key.
* **logical_backup_schedule**
Backup schedule in the cron format. Please take [the reference schedule format](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#schedule) into account. Default: "30 00 \* \* \*"
* **logical_backup_docker_image**
An image for pods of the logical backup job. The [example image](../../docker/logical-backup/Dockerfile)
runs `pg_dumpall` on a replica if possible and uploads compressed results to
an S3 bucket under the key `/spilo/pg_cluster_name/cluster_k8s_uuid/logical_backups`.
The default image is the same image built with the Zalando-internal CI
pipeline. Default: "registry.opensource.zalan.do/acid/logical-backup"
* **logical_backup_s3_bucket**
S3 bucket to store backup results. The bucket has to be present and
accessible by Postgres pods. Default: empty.