mirror of
https://github.com/zalando/postgres-operator.git
synced 2026-10-03 07:31:45 +02:00
resolve conflict with latest config sync
This commit is contained in:
@@ -4,9 +4,9 @@ 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](../../manifests/minimal-postgres-manifest.yaml)
|
||||
[minimal](https://github.com/zalando/postgres-operator/blob/master/manifests/minimal-postgres-manifest.yaml)
|
||||
and the
|
||||
[complete](../../manifests/complete-postgres-manifest.yaml)
|
||||
[complete](https://github.com/zalando/postgres-operator/blob/master/manifests/complete-postgres-manifest.yaml)
|
||||
cluster manifests.
|
||||
|
||||
When Kubernetes resources, such as memory, CPU or volumes, are configured,
|
||||
|
||||
@@ -10,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](../../manifests/configmap.yaml)
|
||||
[example](https://github.com/zalando/postgres-operator/blob/master/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](../../manifests/postgres-operator.yaml#L36)
|
||||
start and uses it for configuration if the [operator deployment manifest](https://github.com/zalando/postgres-operator/blob/master/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.
|
||||
@@ -24,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](../../manifests/postgresql-operator-default-configuration.yaml)
|
||||
the [default one](https://github.com/zalando/postgres-operator/blob/master/manifests/postgresql-operator-default-configuration.yaml)
|
||||
and change it.
|
||||
|
||||
To test the CRD-based configuration locally, use the following
|
||||
@@ -57,11 +57,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 configuration, the [default parameter values](../../pkg/util/config/config.go#L14)
|
||||
For the configmap configuration, the [default parameter values](https://github.com/zalando/postgres-operator/blob/master/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](../../manifests/postgresql-operator-default-configuration.yaml)
|
||||
[operator's default configuration manifest](https://github.com/zalando/postgres-operator/blob/master/manifests/postgresql-operator-default-configuration.yaml)
|
||||
|
||||
Variable names are underscore-separated words.
|
||||
|
||||
@@ -83,7 +83,7 @@ Those are top-level keys, containing both leaf keys and groups.
|
||||
With newer versions of Spilo, it is preferable to use `PGVERSION` pod environment variable instead of the setting `postgresql.bin_dir` in the `SPILO_CONFIGURATION` env variable. When this option is true, the operator sets `PGVERSION` and omits `postgresql.bin_dir` from `SPILO_CONFIGURATION`. When false, the `postgresql.bin_dir` is set. This setting takes precedence over `PGVERSION`; see PR 222 in Spilo. The default is `true`.
|
||||
|
||||
* **enable_spilo_wal_path_compat**
|
||||
enables backwards compatible path between Spilo 12 and Spilo 13 images. The default is `false`.
|
||||
enables backwards compatible path between Spilo 12 and Spilo 13+ images. The default is `false`.
|
||||
|
||||
* **etcd_host**
|
||||
Etcd connection string for Patroni defined as `host:port`. Not required when
|
||||
@@ -154,7 +154,7 @@ Those are top-level keys, containing both leaf keys and groups.
|
||||
cluster nodes. This affects all containers created by the operator (Postgres,
|
||||
Scalyr sidecar, and other sidecars except **sidecars** defined in the operator
|
||||
configuration); to set resources for the operator's own container, change the
|
||||
[operator deployment manually](../../manifests/postgres-operator.yaml#L20).
|
||||
[operator deployment manually](https://github.com/zalando/postgres-operator/blob/master/manifests/postgres-operator.yaml#L20).
|
||||
The default is `false`.
|
||||
|
||||
## Postgres users
|
||||
@@ -186,12 +186,12 @@ CRD-configuration, they are grouped under the `major_version_upgrade` key.
|
||||
|
||||
* **minimal_major_version**
|
||||
The minimal Postgres major version that will not automatically be upgraded
|
||||
when `major_version_upgrade_mode` is set to `"full"`. The default is `"9.5"`.
|
||||
when `major_version_upgrade_mode` is set to `"full"`. The default is `"9.6"`.
|
||||
|
||||
* **target_major_version**
|
||||
The target Postgres major version when upgrading clusters automatically
|
||||
which violate the configured allowed `minimal_major_version` when
|
||||
`major_version_upgrade_mode` is set to `"full"`. The default is `"13"`.
|
||||
`major_version_upgrade_mode` is set to `"full"`. The default is `"14"`.
|
||||
|
||||
## Kubernetes resources
|
||||
|
||||
@@ -217,7 +217,7 @@ configuration they are grouped under the `kubernetes` key.
|
||||
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 explicitly defined by the user, a simple definition that binds the
|
||||
account to the 'postgres-pod' [cluster role](../../manifests/operator-service-account-rbac.yaml#L198)
|
||||
account to the 'postgres-pod' [cluster role](https://github.com/zalando/postgres-operator/blob/master/manifests/operator-service-account-rbac.yaml#L198)
|
||||
will be used. The default is empty.
|
||||
|
||||
* **pod_terminate_grace_period**
|
||||
@@ -602,7 +602,7 @@ Postgres logical backups. In the CRD-based configuration those parameters are
|
||||
grouped under the `logical_backup` key.
|
||||
|
||||
* **logical_backup_docker_image**
|
||||
An image for pods of the logical backup job. The [example image](../../docker/logical-backup/Dockerfile)
|
||||
An image for pods of the logical backup job. The [example image](https://github.com/zalando/postgres-operator/blob/master/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
|
||||
|
||||
Reference in New Issue
Block a user