mirror of
https://github.com/zalando/postgres-operator.git
synced 2026-10-08 06:02:14 +02:00
extend docs and polish manifest examples (#762)
This commit is contained in:
Felix Kunde
+33
-26
@@ -3,6 +3,26 @@
|
||||
Learn how to configure and manage the Postgres Operator in your Kubernetes (K8s)
|
||||
environment.
|
||||
|
||||
## Minor and major version upgrade
|
||||
|
||||
Minor version upgrades for PostgreSQL are handled via updating the Spilo Docker
|
||||
image. The operator will carry out a rolling update of Pods which includes a
|
||||
switchover (planned failover) of the master to the Pod with new minor version.
|
||||
The switch should usually take less than 5 seconds, still clients have to
|
||||
reconnect.
|
||||
|
||||
Major version upgrades are supported via [cloning](user.md#clone-directly). The
|
||||
new cluster manifest must have a higher `version` string than the source cluster
|
||||
and will be created from a basebackup. Depending of the cluster size, downtime
|
||||
in this case can be significant as writes to the database should be stopped and
|
||||
all WAL files should be archived first before cloning is started.
|
||||
|
||||
Note, that simply changing the version string in the `postgresql` manifest does
|
||||
not work at present and leads to errors. Neither Patroni nor Postgres Operator
|
||||
can do in place `pg_upgrade`. Still, it can be executed manually in the Postgres
|
||||
container, which is tricky (i.e. systems need to be stopped, replicas have to be
|
||||
synced) but of course faster than cloning.
|
||||
|
||||
## CRD Validation
|
||||
|
||||
[CustomResourceDefinitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions)
|
||||
@@ -95,8 +115,6 @@ is used by the operator to connect to the clusters after creation.
|
||||
|
||||
## Role-based access control for the operator
|
||||
|
||||
### Service account and cluster roles
|
||||
|
||||
The manifest [`operator-service-account-rbac.yaml`](../manifests/operator-service-account-rbac.yaml)
|
||||
defines the service account, cluster roles and bindings needed for the operator
|
||||
to function under access control restrictions. To deploy the operator with this
|
||||
@@ -109,6 +127,8 @@ kubectl create -f manifests/postgres-operator.yaml
|
||||
kubectl create -f manifests/minimal-postgres-manifest.yaml
|
||||
```
|
||||
|
||||
### Service account and cluster roles
|
||||
|
||||
Note that the service account is named `zalando-postgres-operator`. You may have
|
||||
to change the `service_account_name` in the operator ConfigMap and
|
||||
`serviceAccountName` in the `postgres-operator` deployment appropriately. This
|
||||
@@ -116,12 +136,6 @@ is done intentionally to avoid breaking those setups that already work with the
|
||||
default `operator` account. In the future the operator should ideally be run
|
||||
under the `zalando-postgres-operator` service account.
|
||||
|
||||
The service account defined in `operator-service-account-rbac.yaml` acquires
|
||||
some privileges not used by the operator (i.e. we only need `list` and `watch`
|
||||
on `configmaps` resources). This is also done intentionally to avoid breaking
|
||||
things if someone decides to configure the same service account in the
|
||||
operator's ConfigMap to run Postgres clusters.
|
||||
|
||||
### Give K8s users access to create/list `postgresqls`
|
||||
|
||||
By default `postgresql` custom resources can only be listed and changed by
|
||||
@@ -157,7 +171,6 @@ metadata:
|
||||
name: postgres-operator
|
||||
data:
|
||||
toleration: "key:postgres,operator:Exists,effect:NoSchedule"
|
||||
...
|
||||
```
|
||||
|
||||
For an OperatorConfiguration resource the toleration should be defined like
|
||||
@@ -172,7 +185,6 @@ configuration:
|
||||
kubernetes:
|
||||
toleration:
|
||||
postgres: "key:postgres,operator:Exists,effect:NoSchedule"
|
||||
...
|
||||
```
|
||||
|
||||
Note that the K8s version 1.13 brings [taint-based eviction](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint-based-evictions)
|
||||
@@ -250,7 +262,6 @@ metadata:
|
||||
name: postgres-operator
|
||||
data:
|
||||
inherited_labels: application,environment
|
||||
...
|
||||
```
|
||||
|
||||
**OperatorConfiguration**
|
||||
@@ -265,7 +276,6 @@ configuration:
|
||||
inherited_labels:
|
||||
- application
|
||||
- environment
|
||||
...
|
||||
```
|
||||
|
||||
**cluster manifest**
|
||||
@@ -279,7 +289,7 @@ metadata:
|
||||
application: my-app
|
||||
environment: demo
|
||||
spec:
|
||||
...
|
||||
...
|
||||
```
|
||||
|
||||
**network policy**
|
||||
@@ -294,7 +304,6 @@ spec:
|
||||
matchLabels:
|
||||
application: my-app
|
||||
environment: demo
|
||||
...
|
||||
```
|
||||
|
||||
|
||||
@@ -317,7 +326,6 @@ metadata:
|
||||
data:
|
||||
# referencing config map with custom settings
|
||||
pod_environment_configmap: postgres-pod-config
|
||||
...
|
||||
```
|
||||
|
||||
**OperatorConfiguration**
|
||||
@@ -331,7 +339,6 @@ configuration:
|
||||
kubernetes:
|
||||
# referencing config map with custom settings
|
||||
pod_environment_configmap: postgres-pod-config
|
||||
...
|
||||
```
|
||||
|
||||
**referenced ConfigMap `postgres-pod-config`**
|
||||
@@ -412,12 +419,12 @@ external systems but defined for an individual Postgres cluster in its manifest.
|
||||
A typical example is a role for connections from an application that uses the
|
||||
database.
|
||||
|
||||
* **Human users** originate from the Teams API that returns a list of the team
|
||||
members given a team id. The operator differentiates between (a) product teams
|
||||
that own a particular Postgres cluster and are granted admin rights to maintain
|
||||
it, and (b) Postgres superuser teams that get the superuser access to all
|
||||
Postgres databases running in a K8s cluster for the purposes of maintaining and
|
||||
troubleshooting.
|
||||
* **Human users** originate from the [Teams API](user.md#teams-api-roles) that
|
||||
returns a list of the team members given a team id. The operator differentiates
|
||||
between (a) product teams that own a particular Postgres cluster and are granted
|
||||
admin rights to maintain it, and (b) Postgres superuser teams that get the
|
||||
superuser access to all Postgres databases running in a K8s cluster for the
|
||||
purposes of maintaining and troubleshooting.
|
||||
|
||||
## Understanding rolling update of Spilo pods
|
||||
|
||||
@@ -481,7 +488,7 @@ A secret can be pre-provisioned in different ways:
|
||||
|
||||
With the v1.2 release the Postgres Operator is shipped with a browser-based
|
||||
configuration user interface (UI) that simplifies managing Postgres clusters
|
||||
with the operator. The UI runs with Node.js and comes with it's own docker
|
||||
with the operator. The UI runs with Node.js and comes with it's own Docker
|
||||
image.
|
||||
|
||||
Run NPM to continuously compile `tags/js` code. Basically, it creates an
|
||||
@@ -493,14 +500,14 @@ Run NPM to continuously compile `tags/js` code. Basically, it creates an
|
||||
|
||||
To build the Docker image open a shell and change to the `ui` folder. Then run:
|
||||
|
||||
```
|
||||
```bash
|
||||
docker build -t registry.opensource.zalan.do/acid/postgres-operator-ui:v1.2.0 .
|
||||
```
|
||||
|
||||
Apply all manifests for the `ui/manifests` folder to deploy the Postgres
|
||||
Operator UI on K8s. For local tests you don't need the Ingress resource.
|
||||
|
||||
```
|
||||
```bash
|
||||
kubectl apply -f ui/manifests
|
||||
```
|
||||
|
||||
@@ -510,6 +517,6 @@ to the K8s and Postgres Operator REST API. You can use the provided
|
||||
`run_local.sh` script for this. Make sure it uses the correct URL to your K8s
|
||||
API server, e.g. for minikube it would be `https://192.168.99.100:8443`.
|
||||
|
||||
```
|
||||
```bash
|
||||
./run_local.sh
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user