| 
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