3a9378d3b8
* Up until now, the operator read its own configuration from the configmap. That has a number of limitations, i.e. when the configuration value is not a scalar, but a map or a list. We use a custom code based on github.com/kelseyhightower/envconfig to decode non-scalar values out of plain text keys, but that breaks when the data inside the keys contains both YAML-special elememtns (i.e. commas) and complex quotes, one good example for that is search_path inside `team_api_role_configuration`. In addition, reliance on the configmap forced a flag structure on the configuration, making it hard to write and to read (see https://github.com/zalando-incubator/postgres-operator/pull/308#issuecomment-395131778). The changes allow to supply the operator configuration in a proper YAML file. That required registering a custom CRD to support the operator configuration and provide an example at manifests/postgresql-operator-default-configuration.yaml. At the moment, both old configmap and the new CRD configuration is supported, so no compatibility issues, however, in the future I'd like to deprecate the configmap-based configuration altogether. Contrary to the configmap-based configuration, the CRD one doesn't embed defaults into the operator code, however, one can use the manifests/postgresql-operator-default-configuration.yaml as a starting point in order to build a custom configuration. Since previously `ReadyWaitInterval` and `ReadyWaitTimeout` parameters used to create the CRD were taken from the operator configuration, which is not possible if the configuration itself is stored in the CRD object, I've added the ability to specify them as environment variables `CRD_READY_WAIT_INTERVAL` and `CRD_READY_WAIT_TIMEOUT` respectively. Per review by @zerg-junior and @Jan-M. |
||
|---|---|---|
| cmd | ||
| docker | ||
| docs | ||
| manifests | ||
| pkg | ||
| .gitignore | ||
| .travis.yml | ||
| .zappr.yaml | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| MAINTAINERS | ||
| Makefile | ||
| README.md | ||
| SECURITY.md | ||
| build-ci.sh | ||
| delivery.yaml | ||
| glide.lock | ||
| glide.yaml | ||
| mkdocs.yml | ||
| run_operator_locally.sh | ||
README.md
Postgres Operator
Introduction
The Postgres operator manages PostgreSQL clusters on Kubernetes:
-
The operator watches additions, updates, and deletions of PostgreSQL cluster manifests and changes the running clusters accordingly. For example, when a user submits a new manifest, the operator fetches that manifest and spawns a new Postgres cluster along with all necessary entities such as Kubernetes StatefulSets and Postgres roles. See this Postgres cluster manifest for settings that a manifest may contain.
-
The operator also watches updates to its own configuration and alters running Postgres clusters if necessary. For instance, if a pod docker image is changed, the operator carries out the rolling update. That is, the operator re-spawns one-by-one pods of each StatefulSet it manages with the new Docker image.
-
Finally, the operator periodically synchronizes the actual state of each Postgres cluster with the desired state defined in the cluster's manifest.
There is a browser-friendly version of this documentation at postgres-operator.readthedocs.io
Table of contents
- concepts
- user documentation
- administrator documentation
- developer documentation
- operator configuration reference
- cluster manifest reference
- command-line options and environment variables
the rest of the document is a tutorial to get you up and running with the operator on Minikube.
Quickstart
Prerequisites:
Note that you can also use built-in Kubernetes support in the Docker Desktop
for Mac to follow the steps of this tutorial. You would have to replace
minikube start and minikube delete with your launch actionsfor the Docker
built-in Kubernetes support.
Local execution
git clone https://github.com/zalando-incubator/postgres-operator.git
cd postgres-operator
minikube start
# start the operator; may take a few seconds
kubectl create -f manifests/configmap.yaml # configuration
kubectl create -f manifests/operator-service-account-rbac.yaml # identity and permissions
kubectl create -f manifests/postgres-operator.yaml # deployment
# create a Postgres cluster
kubectl create -f manifests/minimal-postgres-manifest.yaml
# connect to the Postgres master via psql
# operator creates the relevant k8s secret
export HOST_PORT=$(minikube service acid-minimal-cluster --url | sed 's,.*/,,')
export PGHOST=$(echo $HOST_PORT | cut -d: -f 1)
export PGPORT=$(echo $HOST_PORT | cut -d: -f 2)
export PGPASSWORD=$(kubectl get secret postgres.acid-minimal-cluster.credentials -o 'jsonpath={.data.password}' | base64 -d)
psql -U postgres
# tear down cleanly
minikube delete
We have automated starting the operator and submitting the acid-minimal-cluster for you:
cd postgres-operator
./run_operator_locally.sh
Running and testing the operator
The best way to test the operator is to run it in minikube. Minikube is a tool to run Kubernetes cluster locally.
Configuration Options
The operator can be configured with the provided ConfigMap (manifests/configmap.yaml).