minor fixes with alignments

This commit is contained in:
Felix Kunde 2019-07-06 13:46:02 +02:00
parent 39f0ec3ddc
commit 0604b5d9c1
2 changed files with 19 additions and 16 deletions

View File

@ -385,28 +385,29 @@ monitoring is outside of the scope of operator responsibilities.
4. You may use your own image by overwriting the relevant field in the operator 4. You may use your own image by overwriting the relevant field in the operator
configuration. Any such image must ensure the logical backup is able to finish configuration. Any such image must ensure the logical backup is able to finish
[in presence of pod restarts](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#handling-pod-and-container-failures) and [simultaneous invocations](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron-job-limitations) of the backup cron job. [in presence of pod restarts](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/#handling-pod-and-container-failures)
and [simultaneous invocations](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron-job-limitations)
of the backup cron job.
<<<<<<< HEAD
5. For that feature to work, your RBAC policy must enable operations on the 5. For that feature to work, your RBAC policy must enable operations on the
`cronjobs` resource from the `batch` API group for the operator service account. `cronjobs` resource from the `batch` API group for the operator service account.
See [example RBAC](../manifests/operator-service-account-rbac.yaml) See [example RBAC](../manifests/operator-service-account-rbac.yaml)
=======
5. For that feature to work, your RBAC policy must enable operations on the `cronjobs` resource from the `batch` API group for the operator service account. See [example RBAC](../manifests/operator-service-account-rbac.yaml)
## Access to cloud resources from clusters in non cloud environment ## Access to cloud resources from clusters in non cloud environment
To access cloud resources like S3 from a cluster in a bare metal setup you can use To access cloud resources like S3 from a cluster in a bare metal setup you can
`additional_secret_mount` and `additional_secret_mount_path` config parameters. use `additional_secret_mount` and `additional_secret_mount_path` configuration
With this you can provision cloud credentials to the containers in the pods of the StatefulSet. parameters. With this you can provision cloud credentials to the containers in
This works this way that it mounts a volume from the given secret in the pod and this can the pods of the StatefulSet. This works this way that it mounts a volume from
then accessed in the container over the configured mount path. Via [Custum Pod Environment Variables](#custom-pod-environment-variables) the given secret in the pod and this can then accessed in the container over the
you can then point the different cloud sdk's (aws, google etc.) to this mounted secret. configured mount path. Via [Custum Pod Environment Variables](#custom-pod-environment-variables)
With this credentials the cloud sdk can then access cloud resources to upload logs etc. you can then point the different cloud SDK's (AWS, GCP etc.) to this mounted
secret. With this credentials the cloud SDK can then access cloud resources to
upload logs etc.
A secret can be pre provisioned in different ways: A secret can be pre-provisioned in different ways:
* Generic secret created via `kubectl create secret generic some-cloud-creds --from-file=some-cloud-credentials-file.json` * Generic secret created via `kubectl create secret generic some-cloud-creds --from-file=some-cloud-credentials-file.json`
* Automatically provisioned via a Controller like [kube-aws-iam-controller](https://github.com/mikkeloscar/kube-aws-iam-controller).
* Automaticly provisioned via a Controller like [kube-aws-iam-controller](https://github.com/mikkeloscar/kube-aws-iam-controller). This controller would then also rotate the credentials. Please visit the documention for more information. This controller would then also rotate the credentials. Please visit the
>>>>>>> master documention for more information.

View File

@ -422,7 +422,9 @@ Postgres logical backups. In the CRD-based configuration those parameters are
grouped under the `logical_backup` key. grouped under the `logical_backup` key.
* **logical_backup_schedule** * **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 \* \* \*" 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** * **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](../../docker/logical-backup/Dockerfile)