update referece docs
This commit is contained in:
		
							parent
							
								
									d1d2341477
								
							
						
					
					
						commit
						5d0818c402
					
				|  | @ -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 | ||||
|  |  | |||
|  | @ -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. | ||||
| 
 | ||||
|  |  | |||
|  | @ -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. | ||||
|  |  | |||
		Loading…
	
		Reference in New Issue