From 2bb3bdeeb44611c099a68fc4cccdde43271ecfc6 Mon Sep 17 00:00:00 2001 From: Jan M Date: Fri, 4 May 2018 12:20:54 +0200 Subject: [PATCH] Slimming out README and config map, targeting easy first time deployers to minicube. --- README.md | 32 ++++++++--------- manifests/configmap.yaml | 59 ++++++++++++++++---------------- manifests/postgres-operator.yaml | 10 ++---- 3 files changed, 47 insertions(+), 54 deletions(-) diff --git a/README.md b/README.md index a76905303..3fe70fa82 100644 --- a/README.md +++ b/README.md @@ -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 @@ -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 ``` @@ -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), @@ -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. diff --git a/manifests/configmap.yaml b/manifests/configmap.yaml index f3b79e67b..a6ebcf4f3 100644 --- a/manifests/configmap.yaml +++ b/manifests/configmap.yaml @@ -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 @@ -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" diff --git a/manifests/postgres-operator.yaml b/manifests/postgres-operator.yaml index 760451936..a7a8dde49 100644 --- a/manifests/postgres-operator.yaml +++ b/manifests/postgres-operator.yaml @@ -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"