|
3 | 3 | Learn how to configure and manage the Postgres Operator in your Kubernetes (K8s) |
4 | 4 | environment. |
5 | 5 |
|
| 6 | +## CRD registration and validation |
| 7 | + |
| 8 | +On startup, the operator will try to register the necessary |
| 9 | +[CustomResourceDefinitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions) |
| 10 | +`Postgresql` and `OperatorConfiguration`. The latter will only get created if |
| 11 | +the `POSTGRES_OPERATOR_CONFIGURATION_OBJECT` [environment variable](https://github.com/zalando/postgres-operator/blob/master/manifests/postgres-operator.yaml#L36) |
| 12 | +is set in the deployment yaml and is not empty. If the CRDs already exists they |
| 13 | +will only be patched. If you do not wish the operator to create or update the |
| 14 | +CRDs set `enable_crd_registration` config option to `false`. |
| 15 | + |
| 16 | +CRDs are defined with a `openAPIV3Schema` structural schema against which new |
| 17 | +manifests of [`postgresql`](https://github.com/zalando/postgres-operator/blob/master/manifests/postgresql.crd.yaml) or [`OperatorConfiguration`](https://github.com/zalando/postgres-operator/blob/master/manifests/operatorconfiguration.crd.yaml) |
| 18 | +resources will be validated. On creation you can bypass the validation with |
| 19 | +`kubectl create --validate=false`. |
| 20 | + |
| 21 | +By default, the operator will register the CRDs in the `all` category so |
| 22 | +that resources are listed on `kubectl get all` commands. The `crd_categories` |
| 23 | +config option allows for customization of categories. |
| 24 | + |
6 | 25 | ## Upgrading the operator |
7 | 26 |
|
8 | 27 | The Postgres Operator is upgraded by changing the docker image within the |
@@ -63,30 +82,6 @@ upgrade procedure, refer to the [corresponding PR in Spilo](https://github.com/z |
63 | 82 | When `major_version_upgrade_mode` is set to `manual` the operator will run |
64 | 83 | the upgrade script for you after the manifest is updated and pods are rotated. |
65 | 84 |
|
66 | | -## CRD Validation |
67 | | - |
68 | | -[CustomResourceDefinitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions) |
69 | | -will be registered with schema validation by default when the operator is |
70 | | -deployed. The `OperatorConfiguration` CRD will only get created if the |
71 | | -`POSTGRES_OPERATOR_CONFIGURATION_OBJECT` [environment variable](https://github.com/zalando/postgres-operator/blob/master/manifests/postgres-operator.yaml#L36) |
72 | | -in the deployment yaml is set and not empty. |
73 | | - |
74 | | -When submitting manifests of [`postgresql`](https://github.com/zalando/postgres-operator/blob/master/manifests/postgresql.crd.yaml) or |
75 | | -[`OperatorConfiguration`](https://github.com/zalando/postgres-operator/blob/master/manifests/operatorconfiguration.crd.yaml) custom |
76 | | -resources with kubectl, validation can be bypassed with `--validate=false`. The |
77 | | -operator can also be configured to not register CRDs with validation on `ADD` or |
78 | | -`UPDATE` events. Running instances are not affected when enabling the validation |
79 | | -afterwards unless the manifests is not changed then. Note, that the provided CRD |
80 | | -manifests contain the validation for users to understand what schema is |
81 | | -enforced. |
82 | | - |
83 | | -Once the validation is enabled it can only be disabled manually by editing or |
84 | | -patching the CRD manifest: |
85 | | - |
86 | | -```bash |
87 | | -kubectl patch crd postgresqls.acid.zalan.do -p '{"spec":{"validation": null}}' |
88 | | -``` |
89 | | - |
90 | 85 | ## Non-default cluster domain |
91 | 86 |
|
92 | 87 | If your cluster uses a DNS domain other than the default `cluster.local`, this |
|
0 commit comments