Postgres: Postgres docker image 9.6.6 fails to start as kubernetes pod

[bsctl]

Postgres docker image 9.6.6 fails to start as kubernetes pod

I'm trying to start a kubernetes pod with a Postgres 9.6.6 image but the image fails to start

Here the postgres deplyment

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    app: jirapg
  name: jirapg
  namespace:
spec:
  replicas: 1
  selector:
    matchLabels:
      app: jirapg
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: jirapg
    spec:
      containers:
      - env:
        - name: POSTGRES_USER
          value: jiradbuser
        - name: POSTGRES_PASSWORD
          value: jiradbuser
        - name: POSTGRES_DB
          value: jiradb
        image: postgres:9.6.6
        imagePullPolicy: IfNotPresent
        livenessProbe:
          exec:
            command:
            - pg_isready
          failureThreshold: 3
          initialDelaySeconds: 30
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 3
        name: postgres
        ports:
        - containerPort: 5432
          name: postgres
          protocol: TCP
        readinessProbe:
          exec:
            command:
            - pg_isready
          failureThreshold: 3
          initialDelaySeconds: 30
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 2
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /var/lib/postgresql/data
          name: data
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
      volumes:
      - name: data
        emptyDir: {}
#        persistentVolumeClaim:
#          claimName: jirapg-volume-claim

and here the logs from the kubernetes pod

kubectl logs jirapg-6bdd4454ff-htxjq

The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
    pg_ctl -D /var/lib/postgresql/data -l logfile start
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
waiting for server to start....LOG:  database system was shut down at 2017-12-01 14:22:46 UTC
FATAL:  the database system is starting up
.LOG:  MultiXact member wraparound protections are now enabled
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
 done
server started
CREATE DATABASE
CREATE ROLE
/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
LOG:  received fast shutdown request
LOG:  aborting any active transactions
waiting for server to shut down....LOG:  autovacuum launcher shutting down
LOG:  shutting down
LOG:  database system is shut down
 done
server stopped
PostgreSQL init process complete; ready for start up.
LOG:  database system was shut down at 2017-12-01 14:22:59 UTC
LOG:  MultiXact member wraparound protections are now enabled
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started
FATAL:  role "root" does not exist
FATAL:  role "root" does not exist
FATAL:  role "root" does not exist
FATAL:  role "root" does not exist
FATAL:  role "root" does not exist
FATAL:  role "root" does not exist

[yosifkit]

The database looks like it is running fine. That is the correct response when connecting as root since it does not exist. The only user that exists is jiradbuser and it is a superuser.

[qedrakmar]

Because the root user does not exist, you can expand your readinessProbe to the following, and it should correct those FATAL errors:

command:
- pg_isready
- -u
- jiradbuser

[bsctl]

@qedrakmar @yosifkit
So is the readinessProbe responsible for trying to access as root user?
Thanks

[bsctl]

@qedrakmar Here the correct probe
readinessProbe: exec: command: ["pg_isready", "-U", "$(POSTGRES_USER)", "-d", "$(POSTGRES_DB)"]

Thanks