mirror of
https://github.com/zalando/postgres-operator.git
synced 2026-10-06 13:27:41 +02:00
resolve merge conflicts
This commit is contained in:
Sergey Dudoladov
+136
-32
@@ -1,6 +1,6 @@
|
||||
## Create ConfigMap
|
||||
|
||||
ConfigMap is used to store the configuration of the operator
|
||||
A ConfigMap is used to store the configuration of the operator.
|
||||
|
||||
```bash
|
||||
$ kubectl create -f manifests/configmap.yaml
|
||||
@@ -46,7 +46,9 @@ manifests:
|
||||
|
||||
All subsequent `kubectl` commands will work with the `test` namespace. The
|
||||
operator will run in this namespace and look up needed resources - such as its
|
||||
config map - there. Please note that the namespace for service accounts and cluster role bindings in [operator RBAC rules](manifests/operator-service-account-rbac.yaml) needs to be adjusted to the non-default value.
|
||||
ConfigMap - there. Please note that the namespace for service accounts and
|
||||
cluster role bindings in [operator RBAC rules](../manifests/operator-service-account-rbac.yaml)
|
||||
needs to be adjusted to the non-default value.
|
||||
|
||||
## Specify the namespace to watch
|
||||
|
||||
@@ -56,8 +58,10 @@ replicas to 5" and reacting to the requests, in this example by actually
|
||||
scaling up.
|
||||
|
||||
By default, the operator watches the namespace it is deployed to. You can
|
||||
change this by altering the `WATCHED_NAMESPACE` env var in the operator
|
||||
deployment manifest or the `watched_namespace` field in the operator configmap.
|
||||
change this by setting the `WATCHED_NAMESPACE` var in the `env` section of the
|
||||
[operator deployment](../manifests/postgres-operator.yaml) manifest or by
|
||||
altering the `watched_namespace` field in the operator
|
||||
[ConfigMap](../manifests/configmap.yaml#L6).
|
||||
In the case both are set, the env var takes the precedence. To make the
|
||||
operator listen to all namespaces, explicitly set the field/env var to "`*`".
|
||||
|
||||
@@ -75,7 +79,7 @@ in the case database pods need to talk to the Kubernetes API (e.g. when using
|
||||
Kubernetes-native configuration of Patroni). The operator checks that the
|
||||
`pod_service_account_name` exists in the target namespace, and, if not, deploys
|
||||
there the `pod_service_account_definition` from the operator
|
||||
[`Config`](pkg/util/config/config.go) with the default value of:
|
||||
[`Config`](../pkg/util/config/config.go) with the default value of:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
@@ -86,13 +90,13 @@ metadata:
|
||||
|
||||
In this definition, the operator overwrites the account's name to match
|
||||
`pod_service_account_name` and the `default` namespace to match the target
|
||||
namespace. The operator performs **no** further syncing of this account.
|
||||
namespace. The operator performs **no** further syncing of this account.
|
||||
|
||||
## Role-based access control for the operator
|
||||
|
||||
The `manifests/operator-service-account-rbac.yaml` defines cluster roles and bindings needed
|
||||
for the operator to function under access control restrictions. To deploy the
|
||||
operator with this RBAC policy use:
|
||||
The `manifests/operator-service-account-rbac.yaml` defines cluster roles and
|
||||
bindings needed for the operator to function under access control restrictions.
|
||||
To deploy the operator with this RBAC policy use:
|
||||
|
||||
```bash
|
||||
$ kubectl create -f manifests/configmap.yaml
|
||||
@@ -103,18 +107,18 @@ operator with this RBAC policy use:
|
||||
|
||||
Note that the service account in `operator-rbac.yaml` is named
|
||||
`zalando-postgres-operator`. You may have to change the `service_account_name`
|
||||
in the operator configmap and `serviceAccountName` in the postgres-operator
|
||||
in the operator ConfigMap and `serviceAccountName` in the postgres-operator
|
||||
deployment appropriately.
|
||||
|
||||
This is done intentionally, as to avoid breaking those setups that already work
|
||||
This 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-rbac.yaml` acquires some privileges
|
||||
not really used by the operator (i.e. we only need list and watch on
|
||||
configmaps), 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.
|
||||
The service account defined in `operator-rbac.yaml` acquires some privileges
|
||||
not really 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.
|
||||
|
||||
### Use taints and tolerations for dedicated PostgreSQL nodes
|
||||
|
||||
@@ -142,14 +146,101 @@ 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 config map which is used by the Postgres pods as
|
||||
It is possible to configure a ConfigMap which is used by the Postgres pods as
|
||||
an additional provider for environment variables.
|
||||
|
||||
One use case is to customize the Spilo image and configure it with environment
|
||||
variables. The config map with the additional settings is configured in the
|
||||
operator's main config map:
|
||||
variables. The ConfigMap with the additional settings is configured in the
|
||||
operator's main ConfigMap:
|
||||
|
||||
**postgres-operator ConfigMap**
|
||||
|
||||
@@ -186,12 +277,12 @@ instances permitted by each Postgres cluster managed by the operator. If either
|
||||
`min_instances` or `max_instances` is set to a non-zero value, the operator may
|
||||
adjust the number of instances specified in the cluster manifest to match
|
||||
either the min or the max boundary. For instance, of a cluster manifest has 1
|
||||
instance and the min_instances is set to 3, the cluster will be created with 3
|
||||
instances. By default, both parameters are set to -1.
|
||||
instance and the `min_instances` is set to 3, the cluster will be created with 3
|
||||
instances. By default, both parameters are set to `-1`.
|
||||
|
||||
## Load balancers
|
||||
|
||||
For any Postgresql/Spilo cluster, the operator creates two separate k8s
|
||||
For any Postgresql/Spilo cluster, the operator creates two separate Kubernetes
|
||||
services: one for the master pod and one for replica pods. To expose these
|
||||
services to an outer network, one can attach load balancers to them by setting
|
||||
`enableMasterLoadBalancer` and/or `enableReplicaLoadBalancer` to `true` in the
|
||||
@@ -200,28 +291,41 @@ manifest, the operator configmap's settings `enable_master_load_balancer` and
|
||||
`enable_replica_load_balancer` apply. Note that the operator settings affect
|
||||
all Postgresql services running in all namespaces watched by the operator.
|
||||
|
||||
To limit the range of IP adresses that can reach a load balancer, specify desired ranges in the `allowedSourceRanges` field (applies to both master and replica LBs). To prevent exposing LBs to the entire Internet, this field is set at cluster creation time to `127.0.0.1/32` unless overwritten explicitly. If you want to revoke all IP ranges from an existing cluster, please set the `allowedSourceRanges` field to `127.0.0.1/32` or to the empty sequence `[]`. Setting the field to `null` or omitting entirely may lead to k8s removing this field from the manifest due to [the k8s handling of null fields](https://kubernetes.io/docs/concepts/overview/object-management-kubectl/declarative-config/#how-apply-calculates-differences-and-merges-changes). Then the resultant manifest will not have the necessary change, and the operator will respectively do noting with the existing source ranges.
|
||||
To limit the range of IP adresses that can reach a load balancer, specify the
|
||||
desired ranges in the `allowedSourceRanges` field (applies to both master and
|
||||
replica load balancers). To prevent exposing load balancers to the entire
|
||||
Internet, this field is set at cluster creation time to `127.0.0.1/32` unless
|
||||
overwritten explicitly. If you want to revoke all IP ranges from an existing
|
||||
cluster, please set the `allowedSourceRanges` field to `127.0.0.1/32` or to an
|
||||
empty sequence `[]`. Setting the field to `null` or omitting it entirely may
|
||||
lead to Kubernetes removing this field from the manifest due to its
|
||||
[handling of null fields](https://kubernetes.io/docs/concepts/overview/object-management-kubectl/declarative-config/#how-apply-calculates-differences-and-merges-changes).
|
||||
Then the resultant manifest will not contain the necessary change, and the
|
||||
operator will respectively do noting with the existing source ranges.
|
||||
|
||||
## Running periodic 'autorepair' scans of Kubernetes objects
|
||||
|
||||
The Postgres operator periodically scans all Kubernetes objects belonging to
|
||||
each cluster and repairs all discrepancies between them and the definitions
|
||||
generated from the current cluster manifest. There are two types of scans: a
|
||||
`sync scan`, running every `resync_period` seconds for every cluster, and the
|
||||
`repair scan`, coming every `repair_period` only for those clusters that didn't
|
||||
report success as a result of the last operation applied to them.
|
||||
generated from the current cluster manifest. There are two types of scans:
|
||||
|
||||
* `sync scan`, running every `resync_period` seconds for every cluster
|
||||
|
||||
* `repair scan`, coming every `repair_period` only for those clusters that didn't
|
||||
report success as a result of the last operation applied to them.
|
||||
|
||||
## Postgres roles supported by the operator
|
||||
|
||||
The operator is capable of maintaining roles of multiple kinds within a Postgres database cluster:
|
||||
The operator is capable of maintaining roles of multiple kinds within a
|
||||
Postgres database cluster:
|
||||
|
||||
1. **System roles** are roles necessary for the proper work of Postgres itself such as a replication role or the initial superuser role. The operator delegates creating such roles to Patroni and only establishes relevant secrets.
|
||||
* **System roles** are roles necessary for the proper work of Postgres itself such as a replication role or the initial superuser role. The operator delegates creating such roles to Patroni and only establishes relevant secrets.
|
||||
|
||||
2. **Infrastructure roles** are roles for processes originating from external systems, e.g. monitoring robots. The operator creates such roles in all PG clusters it manages assuming k8s secrets with the relevant credentials exist beforehand.
|
||||
* **Infrastructure roles** are roles for processes originating from external systems, e.g. monitoring robots. The operator creates such roles in all Postgres clusters it manages assuming that Kubernetes secrets with the relevant credentials exist beforehand.
|
||||
|
||||
3. **Per-cluster robot users** are also roles for processes originating from 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.
|
||||
* **Per-cluster robot users** are also roles for processes originating from 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.
|
||||
|
||||
4. **Human users** originate from the Teams API that returns list of the team members given a team id. 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 PG databases running in a k8s cluster for the purposes of maintaining and troubleshooting.
|
||||
* **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 Kubernetes cluster for the purposes of maintaining and troubleshooting.
|
||||
|
||||
## Understanding rolling update of Spilo pods
|
||||
|
||||
|
||||
+9
-9
@@ -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
|
||||
@@ -188,13 +188,13 @@ defaults to 4)
|
||||
* /workers/$id/logs - log of the operations performed by a given worker
|
||||
* /clusters/ - list of teams and clusters known to the operator
|
||||
* /clusters/$team - list of clusters for the given team
|
||||
* /cluster/$team/$clustername - detailed status of the cluster, including the
|
||||
* /clusters/$team/$namespace/$clustername - detailed status of the cluster, including the
|
||||
specifications for CRD, master and replica services, endpoints and
|
||||
statefulsets, as well as any errors and the worker that cluster is assigned
|
||||
to.
|
||||
* /cluster/$team/$clustername/logs/ - logs of all operations performed to the
|
||||
* /clusters/$team/$namespace/$clustername/logs/ - logs of all operations performed to the
|
||||
cluster so far.
|
||||
* /cluster/$team/$clustername/history/ - history of cluster changes triggered
|
||||
* /clusters/$team/$namespace/$clustername/history/ - history of cluster changes triggered
|
||||
by the changes of the manifest (shows the somewhat obscure diff and what
|
||||
exactly has triggered the change)
|
||||
|
||||
|
||||
@@ -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 $@
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 7.6 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 253 KiB |
@@ -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}
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 236 KiB |
@@ -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}
|
||||
@@ -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).
|
||||
+4
-4
@@ -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)
|
||||
|
||||
|
||||
+1
-1
@@ -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
|
||||
|
||||
@@ -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,
|
||||
@@ -35,7 +35,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
|
||||
|
||||
@@ -91,7 +99,7 @@ These parameters are 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)
|
||||
@@ -143,7 +151,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
|
||||
@@ -223,7 +231,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
|
||||
@@ -243,7 +251,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
|
||||
|
||||
|
||||
@@ -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,13 +206,21 @@ 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)
|
||||
that should be assigned to the Postgres pods. The priority class itself must be defined in advance.
|
||||
Default is empty (use the default priority class).
|
||||
|
||||
|
||||
* **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
|
||||
|
||||
@@ -229,7 +245,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
|
||||
@@ -294,6 +310,11 @@ In the CRD-based configuration they are grouped under the `load_balancer` key.
|
||||
cluster. Can be overridden by individual cluster settings. The default is
|
||||
`false`.
|
||||
|
||||
* **custom_service_annotations**
|
||||
when load balancing is enabled, LoadBalancer service is created and
|
||||
this parameter takes service annotations that are applied to service.
|
||||
Optional.
|
||||
|
||||
* **master_dns_name_format** defines the DNS name string template for the
|
||||
master load balancer cluster. The default is
|
||||
`{cluster}.{team}.{hostedzone}`, where `{cluster}` is replaced by the cluster
|
||||
@@ -308,12 +329,12 @@ In the CRD-based configuration they are grouped under the `load_balancer` key.
|
||||
replaced with the hosted zone (the value of the `db_hosted_zone` parameter).
|
||||
No other placeholders are allowed.
|
||||
|
||||
## AWS or GSC interaction
|
||||
## AWS or GCP interaction
|
||||
|
||||
The options in this group configure operator interactions with non-Kubernetes
|
||||
objects from AWS or Google cloud. They have no effect unless you are using
|
||||
objects from Amazon Web Services (AWS) or Google Cloud Platform (GCP). They have no effect unless you are using
|
||||
either. In the CRD-based configuration those options are grouped under the
|
||||
`aws_or_gcp` key.
|
||||
`aws_or_gcp` key. Note the GCP integration is not yet officially supported.
|
||||
|
||||
* **wal_s3_bucket**
|
||||
S3 bucket to use for shipping WAL segments with WAL-E. A bucket has to be
|
||||
@@ -345,7 +366,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
|
||||
@@ -461,4 +482,4 @@ scalyr sidecar. In the CRD-based configuration they are grouped under the
|
||||
S3 bucket to store backup results. Default: same as the bucket as for WAL.
|
||||
|
||||
|
||||
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-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)
|
||||
|
||||
+63
-36
@@ -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"
|
||||
@@ -57,25 +57,24 @@ $ psql -U postgres
|
||||
Postgres operator allows defining roles to be created in the resulting database
|
||||
cluster. It covers three use-cases:
|
||||
|
||||
* create application roles specific to the cluster described in the manifest:
|
||||
`manifest roles`.
|
||||
* create application roles that should be automatically created on every
|
||||
cluster managed by the operator: `infrastructure roles`.
|
||||
* automatically create users for every member of the team owning the database
|
||||
cluster: `teams API roles`.
|
||||
* `manifest roles`: create application roles specific to the cluster described in the manifest.
|
||||
* `infrastructure roles`: create application roles that should be automatically created on every
|
||||
cluster managed by the operator.
|
||||
* `teams API roles`: automatically create users for every member of the team owning the database
|
||||
cluster.
|
||||
|
||||
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.
|
||||
|
||||
Manifest roles are defined as a dictionary, with a role name as a key and a
|
||||
list of role options as a value. For a role without any options it is best to supply the empty
|
||||
list `[]`. It is also possible to leave this field empty as in our example manifests, but in certain cases such empty field may removed by Kubernetes [due to the `null` value it gets](https://kubernetes.io/docs/concepts/overview/object-management-kubectl/declarative-config/#how-apply-calculates-differences-and-merges-changes) (`foobar_user:` is equivalent to `foobar_user: null`).
|
||||
list `[]`. It is also possible to leave this field empty as in our example manifests, but in certain cases such empty field may removed by Kubernetes [due to the `null` value it gets](https://kubernetes.io/docs/concepts/overview/object-management-kubectl/declarative-config/#how-apply-calculates-differences-and-merges-changes) (`foobar_user:` is equivalent to `foobar_user: null`).
|
||||
|
||||
The operator accepts the following options: `superuser`, `inherit`, `login`,
|
||||
`nologin`, `createrole`, `createdb`, `replication`, `bypassrls`.
|
||||
@@ -99,10 +98,13 @@ An infrastructure role is a role that should be present on every PostgreSQL
|
||||
cluster managed by the operator. An example of such a role is a monitoring
|
||||
user. There are two ways to define them:
|
||||
|
||||
* Exclusively via the infrastructure roles secret (specified by the
|
||||
`infrastructure_roles_secret_name` parameter).
|
||||
* With the infrastructure roles secret only
|
||||
* With both the the secret and the infrastructure role ConfigMap.
|
||||
|
||||
The role definition looks like this (values are base64 encoded):
|
||||
### Infrastructure roles secret
|
||||
|
||||
The infrastructure roles secret is specified by the `infrastructure_roles_secret_name`
|
||||
parameter. The role definition looks like this (values are base64 encoded):
|
||||
|
||||
```yaml
|
||||
user1: ZGJ1c2Vy
|
||||
@@ -110,25 +112,29 @@ The role definition looks like this (values are base64 encoded):
|
||||
inrole1: b3BlcmF0b3I=
|
||||
```
|
||||
|
||||
A block above describes the infrastructure role 'dbuser' with the password
|
||||
'secret' that is the member of the 'operator' role. For the following
|
||||
The block above describes the infrastructure role 'dbuser' with password
|
||||
'secret' that is a member of the 'operator' role. For the following
|
||||
definitions one must increase the index, i.e. the next role will be defined as
|
||||
'user2' and so on. Note that there is no way to specify role options (like
|
||||
superuser or nologin) this way, and the resulting role will automatically be a
|
||||
login role.
|
||||
'user2' and so on. The resulting role will automatically be a login role.
|
||||
|
||||
* Via both the infrastructure roles secret and the infrastructure role
|
||||
configmap (with the same name as the infrastructure roles secret).
|
||||
Note that with definitions that solely use the infrastructure roles secret
|
||||
there is no way to specify role options (like superuser or nologin) or role
|
||||
memberships. This is where the ConfigMap comes into play.
|
||||
|
||||
The infrastructure roles secret should contain an entry with 'rolename:
|
||||
rolepassword' for each role, and the role description should be specified in
|
||||
the configmap. Below is the example:
|
||||
### Secret plus ConfigMap
|
||||
|
||||
A [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
allows for defining more details regarding the infrastructure roles.
|
||||
Therefore, one should use the new style that specifies infrastructure roles
|
||||
using both the secret and a ConfigMap. The ConfigMap must have the same name as
|
||||
the secret. The secret should contain an entry with 'rolename:rolepassword' for
|
||||
each role.
|
||||
|
||||
```yaml
|
||||
dbuser: c2VjcmV0
|
||||
```
|
||||
|
||||
and the configmap definition for that user:
|
||||
And the role description for that user should be specified in the ConfigMap.
|
||||
|
||||
```yaml
|
||||
data:
|
||||
@@ -140,25 +146,20 @@ and the configmap definition for that user:
|
||||
log_statement: all
|
||||
```
|
||||
|
||||
Note that the definition above allows for more details than the one that relies
|
||||
solely on the infrastructure role secret. In particular, one can allow
|
||||
membership in multiple roles via the `inrole` array parameter, define role
|
||||
flags via the `user_flags` list and supply per-role options through the
|
||||
`db_parameters` dictionary. All those parameters are optional.
|
||||
One can allow membership in multiple roles via the `inrole` array parameter,
|
||||
define role flags via the `user_flags` list and supply per-role options through
|
||||
the `db_parameters` dictionary. All those parameters are optional.
|
||||
|
||||
The definitions that solely use the infrastructure roles secret are more
|
||||
limited and considered legacy ones; one should use the new style that specifies
|
||||
infrastructure roles using both the secret and the configmap. You can mix both
|
||||
in the infrastructure role secret, as long as your new-style definition can be
|
||||
clearly distinguished from the old-style one (for instance, do not name
|
||||
new-style roles`userN`).
|
||||
Both definitions can be mixed in the infrastructure role secret, as long as
|
||||
your new-style definition can be clearly distinguished from the old-style one
|
||||
(for instance, do not name new-style roles `userN`).
|
||||
|
||||
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
|
||||
|
||||
@@ -272,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
|
||||
|
||||
Reference in New Issue
Block a user