[Q&A] Combine this with an in-cluster Postgres?

[IngwiePhoenix]

Hello!

Apologies for posting an issue ticket; Discussions seem to be disabled on this repo.

I had recently been struggling a lot with the Zalando Postgres Operator - having moved the cluster once seemed to have funked it real good and the recovery didn't work as intended. This has led me to look for a "better" solution where I could properly apply users and database credentials right next to the related deployments - which is exactly what this Operator does!

However, I would like to keep my resources in-cluster; my hardware is a little limited in quantity ;)

What would be a good method of applying this against an in-cluster postgres? Any known good charts or deployments that play nice with this?

I only host a few smaller apps like Piped, Shiori and the other odd ones that want a Postgres database - and I plan to use the good old kind: Cronjob to schedule backups.

Thank you and have a great day!

PS.: Your code is an excellent resource for the basics of writing an operator. Been reading it, might try my hand at writing my own in the future!

[IngwiePhoenix]

I spent some time with this and attempted a setup with CloudNativePG - unfortunately, the secret it generates is not compatible with the operator - so I went digging as to what I could do and in the process saw this: https://github.com/movetokube/postgres-operator/blob/master/charts/ext-postgres-operator/templates/operator.yaml#L52-L55

If this behaved just like any pod's .spec.containers[].env section, this could have been an easy solution, I could have just used (...).env[].valueFrom.secretKeyRef to make the CNPG secret work.

Do you know of an alternative as to how to make this work?

Thank you! ^^

EDIT: For reference:

root@cluserboi /m/b/W/Homelab# kubectl get -n postgres secrets
NAME                                 TYPE                       DATA   AGE
default-cluster-app                  kubernetes.io/basic-auth   9      17m
default-cluster-ca                   Opaque                     2      17m
default-cluster-replication          kubernetes.io/tls          2      17m
default-cluster-server               kubernetes.io/tls          2      17m
default-cluster-superuser            kubernetes.io/basic-auth   9      17m
fake-creds                           Opaque                     1      17m
sh.helm.release.v1.mtk-postgres.v1   helm.sh/release.v1         1      14m
root@cluserboi /m/b/W/Homelab# kubectl get -n postgres secrets/default-cluster-superuser -o yaml
apiVersion: v1
data:
  dbname: Kg==
  host: ZGVmYXVsdC1jbHVzdGVyLXJ3
  jdbc-uri: <snip>
  password: <snip>
  pgpass: <snip>
  port: NTQzMg==
  uri: <snip>
  user: cG9zdGdyZXM=
  username: cG9zdGdyZXM=
kind: Secret
metadata:
  annotations:
    cnpg.io/operatorVersion: 1.24.1
  creationTimestamp: "2024-11-03T03:01:21Z"
  labels:
    cnpg.io/cluster: default-cluster
    cnpg.io/reload: "true"
  name: default-cluster-superuser
  namespace: postgres
  ownerReferences:
  - apiVersion: postgresql.cnpg.io/v1
    controller: true
    kind: Cluster
    name: default-cluster
    uid: 6a84eac4-4cc0-4f9a-a05b-f20107e69563
  resourceVersion: "94628645"
  uid: 8f0f7527-7d22-46bb-97ec-c91d14272818
type: kubernetes.io/basic-auth

[kirek007]

I'm using this operator for managing users and database on daily basis in combo with zalando operator. It's quite simple:

1. Zalando created server and super user.(Do not create any other users or databases!)
   2.External secret operator rewrites super user secret for one that can be consumed by this operator
2. Creating Postgres object that manages the database
   So far we're doing multiple restores/clones and haven't seen any issues.

[hitman99]

@kirek007 knows the stuff.