postgres-operator: Cluster dont start

this is my second attempt to create a cluster postgres through this operator. In the first case, i acted in accordance with the instructions in the Readme and deploy it in the minicube. Everything worked out with minikube.

Now I deploy in a separate namespace on the working cluster k8s. The operator unwrapped, finally. But the cluster does not up.

first problem: operator want to use ConfigMap and infrastructure-roles only from Default Namespace second problem: The cluster does not start

# kubectl -n inner get postgresql
NAME         AGE
pg-cluster   21m

cluster definition:

apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: pg-cluster
spec:
  teamId: "PG"
  volume:
    size: 1Gi
    storageclass: rbd
  numberOfInstances: 2
  users:
    # database owner
    root:
    - superuser
    - createdb
    cachet:
    - createdb
    sentry:

    # role for application foo
    # foo_user:

  #databases: name->owner
  databases:
    test: root
    cachet: cachet
    sentry: sentry
  postgresql:
    version: "10"

in operator logs:

# kubectl -n inner logs postgres-operator-56ccbf8d9c-tj8hk
time="2018-02-26T16:26:45Z" level=info msg="customResourceDefinition \"postgresqls.acid.zalan.do\" is already registered" pkg=controller
time="2018-02-26T16:26:48Z" level=info msg="started working in background" pkg=controller
time="2018-02-26T16:26:48Z" level=info msg="listening on :8080" pkg=apiserver
time="2018-02-26T16:26:48Z" level=debug msg="new node has been added: \"/kuber03.lan.local\" ()" pkg=controller
time="2018-02-26T16:26:48Z" level=debug msg="new node has been added: \"/kuber05.lan.local\" ()" pkg=controller
time="2018-02-26T16:26:48Z" level=debug msg="new node has been added: \"/kuber06.lan.local\" ()" pkg=controller
time="2018-02-26T16:26:48Z" level=debug msg="new node has been added: \"/kuber00.lan.local\" ()" pkg=controller
time="2018-02-26T16:26:48Z" level=info msg="no clusters running" pkg=controller
time="2018-02-26T16:31:49Z" level=info msg="no clusters running" pkg=controller
time="2018-02-26T16:40:44Z" level=info msg="no clusters running" pkg=controller
time="2018-02-26T16:46:48Z" level=info msg="no clusters running" pkg=controller
time="2018-02-26T16:51:49Z" level=info msg="no clusters running" pkg=controlle

I still do not understand where else I can look to understand the cluster deploy

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 20 (9 by maintainers)

Most upvoted comments

Strange, do you have a leftover configmap pg-cluster-config from your previous experiments? If you do, please, delete it, one of the pods would pick up the leader role and the other would follow as a replica.

alexeyklyukin on Feb 27, 2018

fix permissions for configmaps Now both pods have in log:

2018-02-27 11:13:19,436 INFO: waiting for leader to bootstrap
2018-02-27 11:13:28,468 INFO: Lock owner: None; I am pg-cluster-0
2018-02-27 11:13:28,471 INFO: waiting for leader to bootstrap
2018-02-27 11:13:38,508 INFO: Lock owner: None; I am pg-cluster-0
2018-02-27 11:13:38,511 INFO: waiting for leader to bootstrap
2018-02-27 11:13:48,540 INFO: Lock owner: None; I am pg-cluster-0
2018-02-27 11:13:48,542 INFO: waiting for leader to bootstrap
2018-02-27 11:13:58,573 INFO: Lock owner: None; I am pg-cluster-0
2018-02-27 11:13:58,576 INFO: waiting for leader to bootstrap

and nothing happens anymore

mobilesfinks on Feb 27, 2018

The operator is configured using the postgres-operator configmap (specified in the CONFIG_MAP_NAME). Inside that configmap, one can specify the service account that the pods created by the operator will run with. That service account requires different permissions from the operator itself.

alexeyklyukin on Feb 27, 2018

Second you can make your users definition simpler, no flags needed anymore unless you really want the user to be able to create more DBs. But we normally don’t give out that power neither superuser.

In that case it comes down to:

users:
  root: []
  cachet: []
  sentry: []

Bump the image version to: 0f392c2 the version u use does work with default but not more, it was hard coded in the manifest back then to make sure it worked.

Jan-M on Feb 26, 2018