diff --git a/docs/quickstart.md b/docs/quickstart.md index 759aaf924..33ba6ed61 100644 --- a/docs/quickstart.md +++ b/docs/quickstart.md @@ -72,10 +72,8 @@ Tiller) in your local cluster you can install the operator chart. You can define a release name that is prepended to the operator resource's names. Use `--name zalando` to match with the default service account name as older -operator versions do not support custom names for service accounts. When relying -solely on the CRD-based configuration use the [values-crd yaml file](../charts/values-crd.yaml) -and comment the ConfigMap template in the [helmignore](../charts/.helmignore) -file. +operator versions do not support custom names for service accounts. To use +CRD-based configuration use the [values-crd yaml file](../charts/values-crd.yaml). ```bash # 1) initialize helm diff --git a/docs/reference/cluster_manifest.md b/docs/reference/cluster_manifest.md index d2bbcbe88..b81b75018 100644 --- a/docs/reference/cluster_manifest.md +++ b/docs/reference/cluster_manifest.md @@ -1,3 +1,5 @@ +# Cluster manifest reference + Individual postgres clusters are described by the Kubernetes *cluster manifest* that has the structure defined by the `postgres CRD` (custom resource definition). The following section describes the structure of the manifest and @@ -201,10 +203,9 @@ explanation of `ttl` and `loop_wait` parameters. ## Postgres container resources -Those parameters define [CPU and memory requests and -limits](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/) +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`. +key with subgroups `requests` and `limits`. ### Requests @@ -218,7 +219,7 @@ CPU and memory requests for the postgres container. 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. @@ -267,7 +268,7 @@ under the `clone` top-level key and do not affect the already running cluster. 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 +## 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. @@ -282,7 +283,7 @@ properties of the persistent storage that stores postgres data. documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/) for the details on storage classes. 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 @@ -300,16 +301,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. @@ -321,7 +317,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. diff --git a/docs/reference/operator_parameters.md b/docs/reference/operator_parameters.md index c9a9db753..1a41394ed 100644 --- a/docs/reference/operator_parameters.md +++ b/docs/reference/operator_parameters.md @@ -1,3 +1,5 @@ +# Configuration parameters + There are two mutually-exclusive methods to set the Postgres Operator configuration. @@ -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 @@ -145,8 +147,7 @@ configuration they are grouped under the `kubernetes` key. 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** @@ -229,8 +230,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** @@ -400,6 +402,26 @@ yet officially supported. * **aws_region** AWS region used to store ESB volumes. The default is `eu-central-1`. + ## 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. @@ -514,24 +536,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.