Skip to content

Commit

Permalink
Slimming out README and config map, targeting easy first time deploye…
Browse files Browse the repository at this point in the history
…rs to minicube.
  • Loading branch information
Jan-M committed May 4, 2018
1 parent 4c8dfd7 commit 2bb3bde
Show file tree
Hide file tree
Showing 3 changed files with 47 additions and 54 deletions.
32 changes: 16 additions & 16 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,25 +6,25 @@

The Postgres operator manages PostgreSQL clusters on Kubernetes using the [operator pattern](https://coreos.com/blog/introducing-operators.html).
During the initial run it registers the [Custom Resource Definition (CRD)](https://kubernetes.io/docs/concepts/api-extension/custom-resources/#customresourcedefinitions) for Postgres.
The PostgreSQL CRD is essentially the schema that describes the contents of the manifests for deploying individual
PostgreSQL clusters using StatefulSets and [Patroni](https://github.com/zalando/patroni).
The `postgresql` CRD is essentially the schema that describes the contents of the manifests for deploying individual
Postgres clusters using StatefulSets and [Patroni](https://github.com/zalando/patroni).

Once the operator is running, it performs the following actions:

* watches for new PostgreSQL cluster manifests and deploys corresponding clusters
* watches for new `postgresql` manifests and deploys new clusters
* watches for updates to existing manifests and changes corresponding properties of the running clusters
* watches for deletes of the existing manifests and deletes corresponding clusters
* acts on an update to the operator definition itself and changes the running clusters when necessary
(i.e. when the docker image inside the operator definition has been updated)
* periodically checks running clusters against the manifests and acts on the differences found
* acts on an update to the operator configuration itself and changes the running clusters when necessary
(i.e. the Docker image changes for a minor release update)
* periodically checks running clusters against the manifests and syncs changes

For instance, when the user creates a new custom object of type ``postgresql`` by submitting a new manifest with
``kubectl``, the operator fetches that object and creates the corresponding Kubernetes structures
(StatefulSets, Services, Secrets) according to its definition.
Example: When a user creates a new custom object of type ``postgresql`` by submitting a new manifest with
``kubectl``, the operator fetches that object and creates the required Kubernetes entities to spawn a new Postgres cluster
(StatefulSets, Services, Secrets).

Another example is changing the docker image inside the operator. In this case, the operator first goes to all StatefulSets
it manages and updates them with the new docker images; afterwards, all pods from each StatefulSet are killed one by one
(rolling upgrade) and the replacements are spawned automatically by each StatefulSet with the new docker image.
Update example: After changing the Docker image inside the operator's configuration, the operator first goes to all StatefulSets
it manages and updates them with the new Docker image; afterwards, all pods from each StatefulSet are killed one by one
and the replacements are spawned automatically by each StatefulSet with the new Docker image. This is called the rolling upgrade.

## Scope

Expand Down Expand Up @@ -147,9 +147,9 @@ We can use the generated secret of the `postgres` robot user to connect to our `
The `manifests/operator-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
kubectl create -f manifests/configmap.yaml
kubectl create -f manifests/operator-rbac.yaml
kubectl create -f manifests/postgres-operator.yaml
kubectl create -f manifests/postgres-operator.yaml
kubectl create -f manifests/minimal-postgres-manifest.yaml
```

Expand All @@ -158,7 +158,7 @@ the `operator` default that is created in the `serviceaccount.yaml`. So you will

This is done intentionally, as 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.
`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),
Expand Down Expand Up @@ -274,7 +274,7 @@ As a preventive measure, one can restrict the minimum and the maximum number of
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.
### Load balancers
### Load balancers
For any Postgresql/Spilo cluster an operator creates two separate k8s 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 cluster manifest. In the case any of these variables is omitted from the 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 a namespace watched by the operator.
Expand Down
59 changes: 29 additions & 30 deletions manifests/configmap.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -2,26 +2,43 @@ apiVersion: v1
kind: ConfigMap
metadata:
name: postgres-operator
data:
# the env var with the same name in the operator pod may overwrite this value
# if neither is set or evaluates to the empty string, listen to the operator's own namespace
data:
# if set to the "*", listen to all namespaces
# watched_namespace: development
cluster_labels: application:spilo
cluster_name_label: version
pod_role_label: spilo-role
db_hosted_zone: db.example.com

debug_logging: "true"
master_dns_name_format: '{cluster}.{team}.staging.{hostedzone}'
replica_dns_name_format: '{cluster}-repl.{team}.staging.{hostedzone}'
workers: "4"
docker_image: registry.opensource.zalan.do/acid/demospilo-10:1.3-p3
secret_name_template: '{username}.{cluster}.credentials'
etcd_host: ""
infrastructure_roles_secret_name: postgresql-infrastructure-roles
oauth_token_secret_name: postgresql-operator
pam_configuration: |
https://info.example.com/oauth2/tokeninfo?access_token= uid realm=/employees
pam_role_name: zalandos
# etcd_host: ""
super_username: postgres
enable_teams_api: "false"
# enable_team_superuser: "false"
# team_admin_role: "admin"
# teams_api_url: http://fake-teams-api.default.svc.cluster.local
# team_api_role_configuration: "log_statement:all"
# infrastructure_roles_secret_name: postgresql-infrastructure-roles
# oauth_token_secret_name: postgresql-operator
# pam_role_name: zalandos
# pam_configuration: |
# https://info.example.com/oauth2/tokeninfo?access_token= uid realm=/employees
db_hosted_zone: db.example.com
master_dns_name_format: '{cluster}.{team}.staging.{hostedzone}'
replica_dns_name_format: '{cluster}-repl.{team}.staging.{hostedzone}'
enable_master_load_balancer: "false"
enable_replica_load_balancer: "false"

pdb_name_format: "postgres-{cluster}-pdb"
node_eol_label: "lifecycle-status:pending-decommission"
node_readiness_label: ""

api_port: "8080"
ring_log_lines: "100"
cluster_history_entries: "1000"
pod_terminate_grace_period: 5m
pod_deletion_wait_timeout: 10m
pod_label_wait_timeout: 10m
ready_wait_interval: 3s
Expand All @@ -30,21 +47,3 @@ data:
resource_check_interval: 3s
resource_check_timeout: 10m
resync_period: 5m
super_username: postgres
enable_teams_api: "false"
enable_team_superuser: "false"
team_admin_role: "admin"
teams_api_url: http://fake-teams-api.default.svc.cluster.local
workers: "4"
# turn on/off load balancers for all Postgres clusters managed by the operator
# LB settings in cluster manifests take priority over these settings
enable_master_load_balancer: "true"
enable_replica_load_balancer: "false"
api_port: "8080"
ring_log_lines: "100"
cluster_history_entries: "1000"
pod_terminate_grace_period: 5m
pdb_name_format: "postgres-{cluster}-pdb"
node_eol_label: "lifecycle-status:pending-decommission"
node_readiness_label: ""
team_api_role_configuration: "log_statement:all"
10 changes: 2 additions & 8 deletions manifests/postgres-operator.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -12,15 +12,9 @@ spec:
serviceAccountName: operator
containers:
- name: postgres-operator
image: registry.opensource.zalan.do/acid/postgres-operator:0f392c2
image: registry.opensource.zalan.do/acid/postgres-operator:4c8dfd7
imagePullPolicy: IfNotPresent
env:
# uncomment to overwrite a similar setting from operator configmap
# if set to the empty string, watch the operator's own namespace
# if set to the "*", listen to all namespaces
# - name: WATCHED_NAMESPACE
# valueFrom:
# fieldRef:
# fieldPath: metadata.namespace
# provided additional ENV vars can overwrite individual config map entries
- name: CONFIG_MAP_NAME
value: "postgres-operator"

0 comments on commit 2bb3bde

Please sign in to comment.