public_git/postgres-operator
1
0
Fork 0
mirror of https://github.com/zalando/postgres-operator.git synced 2026-10-06 18:30:55 +02:00
Code Issues Projects Releases Wiki Activity

complete merging master

Browse Source
This commit is contained in:
Sergey Dudoladov
2019-02-26 13:13:39 +01:00
parent 58aaec63ad 74cc9a44f8
commit 773bc8d20e
92 changed files with 903 additions and 324 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/administrator.md
+87
View File
@@ -146,6 +146,93 @@ data:
...
```
Note that the Kubernetes version 1.13 brings [taint-based eviction](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint-based-evictions) to the beta stage and enables it by default.
Postgres pods by default receive tolerations for `unreachable` and `noExecute` taints with the timeout of `5m`.
Depending on your setup, you may want to adjust these parameters to prevent master pods from being evicted by the Kubernetes runtime.
To prevent eviction completely, specify the toleration by leaving out the `tolerationSeconds` value (similar to how Kubernetes' own DaemonSets are configured)
### Enable pod anti affinity
To ensure Postgres pods are running on different topologies, you can use [pod anti affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/)
and configure the required topology in the operator ConfigMap.
Enable pod anti affinity by adding following line to the operator ConfigMap:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: postgres-operator
data:
enable_pod_antiaffinity: "true"
```
By default the topology key for the pod anti affinity is set to `kubernetes.io/hostname`,
you can set another topology key e.g. `failure-domain.beta.kubernetes.io/zone` by adding following line
to the operator ConfigMap, see [built-in node labels](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#interlude-built-in-node-labels) for available topology keys:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: postgres-operator
data:
enable_pod_antiaffinity: "true"
pod_antiaffinity_topology_key: "failure-domain.beta.kubernetes.io/zone"
```
### Add cluster-specific labels
In some cases, you might want to add `labels` that are specific to a given
postgres cluster, in order to identify its child objects.
The typical use case is to add labels that identifies the `Pods` created by the
operator, in order to implement fine-controlled `NetworkPolicies`.
**OperatorConfiguration**
```yaml
apiVersion: "acid.zalan.do/v1"
kind: OperatorConfiguration
metadata:
name: postgresql-operator-configuration
configuration:
kubernetes:
inherited_labels:
- application
- environment
...
```
**cluster manifest**
```yaml
apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
name: demo-cluster
labels:
application: my-app
environment: demo
spec:
...
```
**network policy**
```yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: netpol-example
spec:
podSelector:
matchLabels:
application: my-app
environment: demo
...
```
## Custom Pod Environment Variables
It is possible to configure a ConfigMap which is used by the Postgres pods as
docs/developer.md
+6 -6
View File
@@ -93,14 +93,14 @@ would create a directory for the GOPATH (i.e. ~/go) and place the source code
under the ~/go/src subdirectories.
Given the schema above, the postgres operator source code located at
`github.com/zalando-incubator/postgres-operator` should be put at
-`~/go/src/github.com/zalando-incubator/postgres-operator`.
`github.com/zalando/postgres-operator` should be put at
-`~/go/src/github.com/zalando/postgres-operator`.
```bash
$ export GOPATH=~/go
$ mkdir -p ${GOPATH}/src/github.com/zalando-incubator/
$ cd ${GOPATH}/src/github.com/zalando-incubator/
$ git clone https://github.com/zalando-incubator/postgres-operator.git
$ mkdir -p ${GOPATH}/src/github.com/zalando/
$ cd ${GOPATH}/src/github.com/zalando/
$ git clone https://github.com/zalando/postgres-operator.git
```
## Building the operator
@@ -157,7 +157,7 @@ The operator employs k8s-provided code generation to obtain deep copy methods an
the `verify-codegen.sh` checks if the generated code is up-to-date (to be used within CI). The `/pkg/generated/` contains the resultant code. To make these scripts work, you may need to `export GOPATH=$(go env GOPATH)`
References for code generation are:
* [Relevant pull request](https://github.com/zalando-incubator/postgres-operator/pull/369)
* [Relevant pull request](https://github.com/zalando/postgres-operator/pull/369)
See comments there for minor issues that can sometimes broke the generation process.
* [Code generator source code](https://github.com/kubernetes/code-generator)
* [Code Generation for CustomResources](https://blog.openshift.com/kubernetes-deep-dive-code-generation-customresources/) - intro post on the topic
docs/diagrams/Makefile
+11
View File
@@ -0,0 +1,11 @@
OBJ=$(patsubst %.tex, %.png, $(wildcard *.tex))
.PHONY: all
all: $(OBJ)
%.pdf: %.tex
lualatex $< -shell-escape $@
%.png: %.pdf
convert -flatten -density 300 $< -quality 90 $@
docs/diagrams/logo.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 7.6 KiB

docs/diagrams/operator.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 253 KiB

docs/diagrams/operator.tex
+101
View File
@@ -0,0 +1,101 @@
\documentclass{article}
\usepackage{tikz}
\usepackage[graphics,tightpage,active]{preview}
\usetikzlibrary{arrows, shadows.blur, positioning, fit, calc, backgrounds}
\usepackage{lscape}
\pagenumbering{gobble}
\PreviewEnvironment{tikzpicture}
\PreviewEnvironment{equation}
\PreviewEnvironment{equation*}
\newlength{\imagewidth}
\newlength{\imagescale}
\pagestyle{empty}
\thispagestyle{empty}
\begin{document}
\begin{center}
\begin{tikzpicture}[
scale=0.5,transform shape,
font=\sffamily,
every matrix/.style={ampersand replacement=\&,column sep=2cm,row sep=2cm},
operator/.style={draw,solid,thick,circle,fill=red!20,inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
component/.style={draw,solid,thick,rounded corners,fill=yellow!20,inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
border/.style={draw,dashed,rounded corners,fill=gray!20,inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
pod/.style={draw,solid,thick,rounded corners,fill=blue!20, inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
service/.style={draw,solid,thick,rounded corners,fill=blue!20, inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
endpoint/.style={draw,solid,thick,rounded corners,fill=blue!20, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
secret/.style={draw,solid,thick,rounded corners,fill=blue!20, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
pvc/.style={draw,solid,thick,rounded corners,fill=blue!20, inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
label/.style={rectangle,inner sep=0,outer sep=0},
to/.style={->,>=stealth',shorten >=1pt,semithick,font=\sffamily\footnotesize},
every node/.style={align=center}]
% Position the nodes using a matrix layout
\matrix{
\& \node[component] (crd) {CRD}; \\
\& \node[operator] (operator) {Operator}; \\
\path
node[service] (service-master) {Master}
node[label, right of=service-master] (service-middle) {}
node[label, below of=service-middle] (services-label) {Services}
node[service, right=.5cm of service-master] (service-replica) {Replica}
node[border, behind path,
fit=(service-master)(service-replica)(services-label)
] (services) {};
\&
\node[component] (sts) {Statefulset}; \& \node[component] (pdb) {Pod Disruption Budget}; \\
\path
node[service] (master-endpoint) {Master}
node[service, right=.5cm of master-endpoint] (replica-endpoint) {Replica}
node[label, right of=master-endpoint] (endpoint-middle) {}
node[label, below of=endpoint-middle] (endpoint-label) {Endpoints}
node[border, behind path,
fit=(master-endpoint)(replica-endpoint)(endpoint-label)
] (endpoints) {}; \&
\node[component] (pod-template) {Pod Template}; \&
\node[border] (secrets) {
\begin{tikzpicture}[]
\node[secret] (users-secret) at (0, 0) {Users};
\node[secret] (robots-secret) at (2, 0) {Robots};
\node[secret] (standby-secret) at (4, 0) {Standby};
\end{tikzpicture} \\
Secrets
}; \\ \&
\path
node[pod] (replica1-pod) {Replica}
node[pod, left=.5cm of replica1-pod] (master-pod) {Master}
node[pod, right=.5cm of replica1-pod] (replica2-pod) {Replica}
node[label, below of=replica1-pod] (pod-label) {Pods}
node[border, behind path,
fit=(master-pod)(replica1-pod)(replica2-pod)(pod-label)
] (pods) {}; \\ \&
\path
node[pvc] (replica1-pvc) {Replica}
node[pvc, left=.5cm of replica1-pvc] (master-pvc) {Master}
node[pvc, right=.5cm of replica1-pvc] (replica2-pvc) {Replica}
node[label, below of=replica1-pvc] (pvc-label) {Persistent Volume Claims}
node[border, behind path,
fit=(master-pvc)(replica1-pvc)(replica2-pvc)(pvc-label)
] (pvcs) {}; \&
\\ \& \\
};
% Draw the arrows between the nodes and label them.
\draw[to] (crd) -- node[midway,above] {} node[midway,below] {} (operator);
\draw[to] (operator) -- node[midway,above] {} node[midway,below] {} (sts);
\draw[to] (operator) -- node[midway,above] {} node[midway,below] {} (secrets);
\draw[to] (operator) -| node[midway,above] {} node[midway,below] {} (pdb);
\draw[to] (service-master) -- node[midway,above] {} node[midway,below] {} (master-endpoint);
\draw[to] (service-replica) -- node[midway,above] {} node[midway,below] {} (replica-endpoint);
\draw[to] (master-pod) -- node[midway,above] {} node[midway,below] {} (master-pvc);
\draw[to] (replica1-pod) -- node[midway,above] {} node[midway,below] {} (replica1-pvc);
\draw[to] (replica2-pod) -- node[midway,above] {} node[midway,below] {} (replica2-pvc);
\draw[to] (operator) -| node[midway,above] {} node[midway,below] {} (services);
\draw[to] (sts) -- node[midway,above] {} node[midway,below] {} (pod-template);
\draw[to] (pod-template) -- node[midway,above] {} node[midway,below] {} (pods);
\end{tikzpicture}
\end{center}
\end{document}
docs/diagrams/pod.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 236 KiB

docs/diagrams/pod.tex
+92
View File
@@ -0,0 +1,92 @@
\documentclass{article}
\usepackage{tikz}
\usepackage[graphics,tightpage,active]{preview}
\usetikzlibrary{arrows, shadows.blur, positioning, fit, calc, backgrounds}
\usepackage{lscape}
\pagenumbering{gobble}
\PreviewEnvironment{tikzpicture}
\PreviewEnvironment{equation}
\PreviewEnvironment{equation*}
\newlength{\imagewidth}
\newlength{\imagescale}
\pagestyle{empty}
\thispagestyle{empty}
\begin{document}
\begin{center}
\begin{tikzpicture}[
scale=0.5,transform shape,
font=\sffamily,
every matrix/.style={ampersand replacement=\&,column sep=2cm,row sep=2cm},
pod/.style={draw,solid,thick,circle,fill=red!20,inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
component/.style={draw,solid,thick,rounded corners,fill=yellow!20,inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
border/.style={draw,dashed,rounded corners,fill=gray!20,inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
volume/.style={draw,solid,thick,rounded corners,fill=blue!20, inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
sidecar/.style={draw,solid,thick,rounded corners,fill=blue!20, inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
k8s-label/.style={draw,solid,thick,rounded corners,fill=blue!20, minimum width=1.5cm, inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
affinity/.style={draw,solid,thick,rounded corners,fill=blue!20, minimum width=2cm, inner sep=.3cm, blur shadow={shadow blur steps=5,shadow blur extra rounding=1.3pt}},
label/.style={rectangle,inner sep=0,outer sep=0},
to/.style={->,>=stealth',shorten >=1pt,semithick,font=\sffamily\footnotesize},
every node/.style={align=center}]
% Position the nodes using a matrix layout
\matrix{
\path
node[k8s-label] (app-label) {App}
node[k8s-label, right=.25cm of app-label] (role-label) {Role}
node[k8s-label, right=.25cm of role-label] (custom-label) {Custom}
node[label, below of=role-label] (k8s-label-label) {K8S Labels}
node[border, behind path,
fit=(app-label)(role-label)(custom-label)(k8s-label-label)
] (k8s-labels) {}; \& \&
\path
node[affinity] (affinity) {Affinity}
node[label, right=.25cm of affinity] (affinity-middle) {}
node[affinity, right=.25cm of affinity-middle] (anti-affinity) {Anti-affinity}
node[label, below of=affinity-middle] (affinity-label) {Assigning to nodes}
node[border, behind path,
fit=(affinity)(anti-affinity)(affinity-label)
] (affinity) {}; \\
\& \node[pod] (pod) {Pod}; \& \\
\path
node[volume, minimum width={width("shm-volume")}] (data-volume) {Data}
node[volume, right=.25cm of data-volume, minimum width={width("shm-volume")}] (tokens-volume) {Tokens}
node[volume, right=.25cm of tokens-volume] (shm-volume) {/dev/shm}
node[label, below of=tokens-volume] (volumes-label) {Volumes}
node[border, behind path,
fit=(data-volume)(shm-volume)(tokens-volume)(volumes-label)
] (volumes) {}; \&
\node[component] (spilo) {Spilo}; \&
\node[sidecar] (scalyr) {Scalyr}; \& \\ \&
\path
node[component] (patroni) {Patroni}
node[component, below=.25cm of patroni] (postgres) {PostgreSQL}
node[border, behind path,
fit=(postgres)(patroni)
] (spilo-components) {}; \&
\path
node[sidecar] (custom-sidecar1) {User defined}
node[label, right=.25cm of custom-sidecar1] (sidecars-middle) {}
node[sidecar, right=.25cm of sidecars-middle] (custom-sidecar2) {User defined}
node[label, below of=sidecars-middle] (sidecars-label) {Custom sidecars}
node[border, behind path,
fit=(custom-sidecar1)(custom-sidecar2)(sidecars-label)
] (sidecars) {};
\\ \& \\
};
% Draw the arrows between the nodes and label them.
\draw[to] (pod) to [bend left=25] (volumes);
\draw[to] (pod) to [bend left=25] (k8s-labels);
\draw[to] (pod) to [bend right=25] (affinity);
\draw[to] (pod) to [bend right=25] (scalyr);
\draw[to] (pod) to [bend right=25] (sidecars);
\draw[to] (pod) -- node[midway,above] {} node[midway,below] {} (spilo);
\draw[to] (spilo) -- node[midway,above] {} node[midway,below] {} (spilo-components);
\end{tikzpicture}
\end{center}
\end{document}
docs/gsoc-2019/ideas.md
+64
View File
@@ -0,0 +1,64 @@
# Google Summer of Code 2019
## Applications steps
1. Please carefully read the official [Google Summer of Code Student Guide](https://google.github.io/gsocguides/student/)
2. Join the #postgres-operator slack channel under [Postgres Slack](https://postgres-slack.herokuapp.com) to introduce yourself to the community and get quick feedback on your application.
3. Select a project from the list of ideas below or propose your own.
4. Write a proposal draft. Please open an issue with the label `gsoc2019_application` in the [operator repository](https://github.com/zalando/postgres-operator/issues) so that the community members can publicly review it. See proposal instructions below for details.
5. Submit proposal and the proof of enrollment before April 9 2019 18:00 UTC through the web site of the Program.
## Project ideas
### Place database pods into the "Guaranteed" Quality-of-Service class
* **Description**: Kubernetes runtime does not kill pods in this class on condition they stay within their resource limits, which is desirable for the DB pods serving production workloads. To be assigned to that class, pod's resources must equal its limits. The task is to add the `enableGuaranteedQoSClass` or the like option to the Postgres manifest and the operator configmap that forcibly re-write pod resources to match the limits.
* **Recommended skills**: golang, basic Kubernetes abstractions
* **Difficulty**: moderate
* **Mentor(s)**: Felix Kunde [@FxKu](https://github.com/fxku), Sergey Dudoladov [@sdudoladov](https://github.com/sdudoladov)
### Implement the kubectl plugin for the Postgres CustomResourceDefinition
* **Description**: [kubectl plugins](https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/) enable extending the Kubernetes command-line client `kubectl` with commands to manage custom resources. The task is to design and implement a plugin for the `kubectl postgres` command,
that can enable, for example, correct deletion or major version upgrade of Postgres clusters.
* **Recommended skills**: golang, shell scripting, operational experience with Kubernetes
* **Difficulty**: moderate to medium, depending on the plugin design
* **Mentor(s)**: Felix Kunde [@FxKu](https://github.com/fxku), Sergey Dudoladov [@sdudoladov](https://github.com/sdudoladov)
### Implement the openAPIV3Schema for the Postgres CRD
* **Description**: at present the operator validates a database manifest on its own.
It will be helpful to reject erroneous manifests before they reach the operator using the [native Kubernetes CRD validation](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#validation). It is up to the student to decide whether to write the schema manually or to adopt existing [schema generator developed for the Prometheus project](https://github.com/ant31/crd-validation).
* **Recommended skills**: golang, JSON schema
* **Difficulty**: medium
* **Mentor(s)**: Sergey Dudoladov [@sdudoladov](https://github.com/sdudoladov)
* **Issue**: [#388](https://github.com/zalando/postgres-operator/issues/388)
### Design a solution for the local testing of the operator
* **Description**: The current way of testing is to run minikube, either manually or with some tooling around it like `/run-operator_locally.sh` or Vagrant. This has at least three problems:
First, minikube is a single node cluster, so it is unsuitable for testing vital functions such as pod migration between nodes. Second, minikube starts slowly; that prolongs local testing.
Third, every contributor needs to come up with their own solution for local testing. The task is to come up with a better option which will enable us to conveniently and uniformly run e2e tests locally / potentially in Travis CI.
A promising option is the Kubernetes own [kind](https://github.com/kubernetes-sigs/kind)
* **Recommended skills**: Docker, shell scripting, basic Kubernetes abstractions
* **Difficulty**: medium to hard depending on the selected desing
* **Mentor(s)**: Dmitry Dolgov [@erthalion](https://github.com/erthalion), Sergey Dudoladov [@sdudoladov](https://github.com/sdudoladov)
* **Issue**: [#475](https://github.com/zalando/postgres-operator/issues/475)
### Detach a Postgres cluster from the operator for maintenance
* **Description**: sometimes a Postgres cluster requires manual maintenance. During such maintenance the operator should ignore all the changes manually applied to the cluster.
Currently the only way to achieve this behavior is to shutdown the operator altogether, for instance by scaling down the operator's own deployment to zero pods. That approach evidently affects all Postgres databases under the operator control and thus is highly undesirable in production Kubernetes clusters. It would be much better to be able to detach only the desired Postgres cluster from the operator for the time being and re-attach it again after maintenance.
* **Recommended skills**: golang, architecture of a Kubernetes operator
* **Difficulty**: hard - requires significant modification of the operator's internals and careful consideration of the corner cases.
* **Mentor(s)**: Dmitry Dolgov [@erthalion](https://github.com/erthalion), Sergey Dudoladov [@sdudoladov](https://github.com/sdudoladov)
* **Issue**: [#421](https://github.com/zalando/postgres-operator/issues/421)
### Propose your own idea
Feel free to come up with your own ideas. For inspiration,
see [our bug tracker](https://github.com/zalando/postgres-operator/issues),
the [official `CustomResouceDefinition` docs](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
and [other operators](https://github.com/operator-framework/awesome-operators).
docs/index.md
+4 -4
View File
@@ -8,10 +8,10 @@ manages PostgreSQL clusters on Kubernetes:
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](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/complete-postgres-manifest.yaml)
[Postgres cluster manifest](https://github.com/zalando/postgres-operator/blob/master/manifests/complete-postgres-manifest.yaml)
for settings that a manifest may contain.
2. The operator also watches updates to [its own configuration](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/configmap.yaml)
2. The operator also watches updates to [its own configuration](https://github.com/zalando/postgres-operator/blob/master/manifests/configmap.yaml)
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
@@ -47,11 +47,11 @@ the operator is deployed to multiple Kubernetes clusters, where users deploy
manifests via our CI/CD infrastructure or rely on a slim user interface to
create manifests.
Please, report any issues discovered to https://github.com/zalando-incubator/postgres-operator/issues.
Please, report any issues discovered to https://github.com/zalando/postgres-operator/issues.
## Talks
1. "PostgreSQL and Kubernetes: DBaaS without a vendor-lock" talk by Oleksii Kliukin, PostgreSQL Sessions 2018: [slides](https://speakerdeck.com/alexeyklyukin/postgresql-and-kubernetes-dbaas-without-a-vendor-lock)
1. "PostgreSQL and Kubernetes: DBaaS without a vendor-lock" talk by Oleksii Kliukin, PostgreSQL Sessions 2018: [video](https://www.youtube.com/watch?v=q26U2rQcqMw) | [slides](https://speakerdeck.com/alexeyklyukin/postgresql-and-kubernetes-dbaas-without-a-vendor-lock)
2. "PostgreSQL High Availability on Kubernetes with Patroni" talk by Oleksii Kliukin, Atmosphere 2018: [video](https://www.youtube.com/watch?v=cFlwQOPPkeg) | [slides](https://speakerdeck.com/alexeyklyukin/postgresql-high-availability-on-kubernetes-with-patroni)
docs/quickstart.md
+1 -1
View File
@@ -13,7 +13,7 @@ built-in Kubernetes support.
## Local execution
```bash
git clone https://github.com/zalando-incubator/postgres-operator.git
git clone https://github.com/zalando/postgres-operator.git
cd postgres-operator
minikube start
docs/reference/cluster_manifest.md
+15 -7
View File
@@ -3,9 +3,9 @@ Individual postgres clusters are described by the Kubernetes *cluster manifest*
that has the structure defined by the `postgres CRD` (custom resource
definition). The following section describes the structure of the manifest and
the purpose of individual keys. You can take a look at the examples of the
[minimal](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/minimal-postgres-manifest.yaml)
[minimal](https://github.com/zalando/postgres-operator/blob/master/manifests/minimal-postgres-manifest.yaml)
and the
[complete](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/complete-postgres-manifest.yaml)
[complete](https://github.com/zalando/postgres-operator/blob/master/manifests/complete-postgres-manifest.yaml)
cluster manifests.
When Kubernetes resources, such as memory, CPU or volumes, are configured,
@@ -33,7 +33,15 @@ Those parameters are grouped under the `metadata` top-level key.
services, secrets) for the cluster. Changing it after the cluster creation
results in deploying or updating a completely separate cluster in the target
namespace. Optional (if present, should match the namespace where the
manifest is applied).
manifest is applied).
* **labels**
if labels are matching one of the `inherited_labels` [configured in the
operator parameters](operator_parameters.md#kubernetes-resources),
they will automatically be added to all the objects (StatefulSet, Service,
Endpoints, etc.) that are created by the operator.
Labels that are set here but not listed as `inherited_labels` in the operator
parameters are ignored.
## Top-level parameters
@@ -89,7 +97,7 @@ Those are parameters grouped directly under the `spec` key in the manifest.
examples](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)
for details on tolerations and possible values of those keys. When set, this
value overrides the `pod_toleration` setting from the operator. Optional.
* **podPriorityClassName**
a name of the [priority
class](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass)
@@ -135,7 +143,7 @@ explanation of `ttl` and `loop_wait` parameters.
a map of key-value pairs describing initdb parameters. For `data-checksum`,
`debug`, `no-locale`, `noclean`, `nosync` and `sync-only` parameters use
`true` as the value if you want to set them. Changes to this option do not
affect the already initialized clusters. Optional.
affect the already initialized clusters. Optional.
* **pg_hba**
list of custom `pg_hba` lines to replace default ones. Note that the default
@@ -215,7 +223,7 @@ under the `clone` top-level key and do not affect the already running cluster.
different namespaces) , the operator uses UID in the S3 bucket name in order
to guarantee uniqueness. Has no effect when cloning from the running
clusters. Optional.
* **timestamp**
the timestamp up to which the recovery should proceed. The operator always
configures non-inclusive recovery target, stopping right before the given
@@ -235,7 +243,7 @@ properties of the persistent storage that stores postgres data.
the name of the Kubernetes storage class to draw the persistent volume from.
See [Kubernetes
documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/)
for the details on storage classes. Optional.
for the details on storage classes. Optional.
### Sidecar definitions
docs/reference/operator_parameters.md
+26 -10
View File
@@ -8,20 +8,20 @@ configuration.
maps. String values containing ':' should be enclosed in quotes. The
configuration is flat, parameter group names below are not reflected in the
configuration structure. There is an
[example](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/configmap.yaml)
[example](https://github.com/zalando/postgres-operator/blob/master/manifests/configmap.yaml)
* CRD-based configuration. The configuration is stored in a custom YAML
manifest. The manifest is an instance of the custom resource definition (CRD) called
`OperatorConfiguration`. The operator registers this CRD
during the start and uses it for configuration if the [operator deployment manifest ](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/postgres-operator.yaml#L21) sets the `POSTGRES_OPERATOR_CONFIGURATION_OBJECT` env variable to a non-empty value. The variable should point to the
`OperatorConfiguration`. The operator registers this CRD
during the start and uses it for configuration if the [operator deployment manifest ](https://github.com/zalando/postgres-operator/blob/master/manifests/postgres-operator.yaml#L21) sets the `POSTGRES_OPERATOR_CONFIGURATION_OBJECT` env variable to a non-empty value. The variable should point to the
`postgresql-operator-configuration` object in the operator's namespace.
The CRD-based configuration is a regular YAML
document; non-scalar keys are simply represented in the usual YAML way.
document; non-scalar keys are simply represented in the usual YAML way.
There are no default values built-in in the operator, each parameter that is
not supplied in the configuration receives an empty value. In order to
create your own configuration just copy the [default
one](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/postgresql-operator-default-configuration.yaml)
one](https://github.com/zalando/postgres-operator/blob/master/manifests/postgresql-operator-default-configuration.yaml)
and change it.
To test the CRD-based configuration locally, use the following
@@ -172,6 +172,14 @@ configuration they are grouped under the `kubernetes` key.
list of `name:value` pairs for additional labels assigned to the cluster
objects. The default is `application:spilo`.
* **inherited_labels**
list of labels that can be inherited from the cluster manifest, and added to
each child objects (`StatefulSet`, `Pod`, `Service` and `Endpoints`) created by
the opertor.
Typical use case is to dynamically pass labels that are specific to a given
postgres cluster, in order to implement `NetworkPolicy`.
The default is empty.
* **cluster_name_label**
name of the label assigned to Kubernetes objects created by the operator that
indicates which cluster a given object belongs to. The default is
@@ -198,7 +206,7 @@ configuration they are grouped under the `kubernetes` key.
All variables from that ConfigMap are injected to the pod's environment, on
conflicts they are overridden by the environment variables generated by the
operator. The default is empty.
* **pod_priority_class_name**
a name of the [priority
class](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass)
@@ -209,7 +217,15 @@ configuration they are grouped under the `kubernetes` key.
The period of time to wait for the success of Patroni switchovers from master pods on an unschedulable node
to their respective replicas on healthy nodes. The situation where master pods still exist on the old node
after this timeout expires has to be fixed manually. The default is 10 minutes.
* **enable_pod_antiaffinity**
toggles [pod anti affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/) on the Postgres pods, to avoid multiple pods
of the same Postgres cluster in the same topology , e.g. node. The default is `false`.
* **pod_antiaffinity_topology_key**
override
[topology key](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#interlude-built-in-node-labels)
for pod anti affinity. The default is `kubernetes.io/hostname`.
## Kubernetes resource requests
@@ -234,7 +250,7 @@ CRD-based configuration.
settings. The default is `1Gi`.
* **set_memory_request_to_limit**
Set `memory_request` to `memory_limit` for all Postgres clusters (the default value is also increased). This prevents certain cases of memory overcommitment at the cost of overprovisioning memory and potential scheduling problems for containers with high memory limits due to the lack of memory on Kubernetes cluster nodes. This affects all containers created by the operator (Postgres, Scalyr sidecar, and other sidecars); to set resources for the operator's own container, change the [operator deployment manually](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/postgres-operator.yaml#L13). The default is `false`.
Set `memory_request` to `memory_limit` for all Postgres clusters (the default value is also increased). This prevents certain cases of memory overcommitment at the cost of overprovisioning memory and potential scheduling problems for containers with high memory limits due to the lack of memory on Kubernetes cluster nodes. This affects all containers created by the operator (Postgres, Scalyr sidecar, and other sidecars); to set resources for the operator's own container, change the [operator deployment manually](https://github.com/zalando/postgres-operator/blob/master/manifests/postgres-operator.yaml#L13). The default is `false`.
* **enable_shm_volume**
Instruct operator to start any new database pod without limitations on shm
@@ -355,7 +371,7 @@ Options to aid debugging of the operator itself. Grouped under the `debug` key.
boolean parameter that toggles the functionality of the operator that require
access to the postgres database, i.e. creating databases and users. The default
is `true`.
## Automatic creation of human users in the database
Options to automate creation of human users with the aid of the teams API
@@ -453,4 +469,4 @@ scalyr sidecar. In the CRD-based configuration they are grouped under the
Memory limit value for the Scalyr sidecar. The default is `1Gi`.
For the configmap operator configuration, the [default parameter values](https://github.com/zalando-incubator/postgres-operator/blob/master/pkg/util/config/config.go#L14) mentioned here are likely to be overwritten in your local operator installation via your local version of the operator configmap. In the case you use the operator CRD, all the CRD defaults are provided in the [operator's default configuration manifest](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/postgresql-operator-default-configuration.yaml)
For the configmap operator configuration, the [default parameter values](https://github.com/zalando/postgres-operator/blob/master/pkg/util/config/config.go#L14) mentioned here are likely to be overwritten in your local operator installation via your local version of the operator configmap. In the case you use the operator CRD, all the CRD defaults are provided in the [operator's default configuration manifest](https://github.com/zalando/postgres-operator/blob/master/manifests/postgresql-operator-default-configuration.yaml)
docs/user.md
+30 -4
View File
@@ -1,7 +1,7 @@
## Create a manifest for a new PostgreSQL cluster
As an example you can take this
[minimal example](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/minimal-postgres-manifest.yaml):
[minimal example](https://github.com/zalando/postgres-operator/blob/master/manifests/minimal-postgres-manifest.yaml):
```yaml
apiVersion: "acid.zalan.do/v1"
@@ -68,7 +68,7 @@ In the next sections, we will cover those use cases in more details.
## Manifest roles
Manifest roles are defined directly in the cluster manifest. See
[minimal postgres manifest](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/minimal-postgres-manifest.yaml)
[minimal postgres manifest](https://github.com/zalando/postgres-operator/blob/master/manifests/minimal-postgres-manifest.yaml)
for an example of `zalando` role, defined with `superuser` and `createdb`
flags.
@@ -158,8 +158,8 @@ Since an infrastructure role is created uniformly on all clusters managed by
the operator, it makes no sense to define it without the password. Such
definitions will be ignored with a prior warning.
See [infrastructure roles secret](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/infrastructure-roles.yaml)
and [infrastructure roles configmap](https://github.com/zalando-incubator/postgres-operator/blob/master/manifests/infrastructure-roles-configmap.yaml) for the examples.
See [infrastructure roles secret](https://github.com/zalando/postgres-operator/blob/master/manifests/infrastructure-roles.yaml)
and [infrastructure roles configmap](https://github.com/zalando/postgres-operator/blob/master/manifests/infrastructure-roles-configmap.yaml) for the examples.
## Use taints and tolerations for dedicated PostgreSQL nodes
@@ -273,6 +273,32 @@ are always passed to sidecars:
The PostgreSQL volume is shared with sidecars and is mounted at `/home/postgres/pgdata`.
## InitContainers Support
Each cluster can specify arbitrary init containers to run. These containers can be
used to run custom actions before any normal and sidecar containers start.
An init container can be specified like this:
```yaml
apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
name: acid-minimal-cluster
spec:
...
init_containers:
- name: "container-name"
image: "company/image:tag"
env:
- name: "ENV_VAR_NAME"
value: "any-k8s-env-things"
```
`init_containers` accepts full `v1.Container` definition.
## Increase volume size
PostgreSQL operator supports statefulset volume resize if you're using the