minor fixes with alignments
This commit is contained in:
parent
39f0ec3ddc
commit
0604b5d9c1
|
|
@ -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.
|
||||||
|
|
|
||||||
|
|
@ -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)
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue