question: postgres instance & connection pooler instance scheduling

[AVVS]

Currently the way I see it they both share node affinity / anti affinity / tolerations I wanted to make sure that when scheduling and executing poolers would be on dedicated pooler nodes, postgres instances would be on dedicated postgres nodes & anti affinity would take care of cross-zone HA

is there something I'm missing in the docs that allows me to do that or its currently not possible? Thanks!

[FxKu]

Yes they share the node affinities, since it was a request by the community (#1441). Individual pooler affinities are not supported, but probably possible to implement for the connection pooler config struct by someone (not us).

[mwoodbri]

This is also an issue for us - we'd love to upgrade to v1.7+ but we have dedicated nodes for spilo pods, so can't allow pgbouncer pods to be scheduled on same nodes. Even if we could, we only have two such nodes which would prevent a rolling upgrade of pgbouncer unless we could configure the update policy (#1600). Would like to be able to help with this but a complete Go novice!

[ibot3]

It's currently also a problem for arm64 setups. The pooler currently does not work on arm64, so I would like to run the postgres instances on arm64 and the pooler on amd64. Is there any way to do that?

[davidfrickert]

in case anyone comes with the issue of pooler not having an arm image and no way to configure affinity / nodeselector, and you happen to use ArgoCD, you can do this:

Ensure your Application has Server Side Apply enabled:

syncOptions:
      - ServerSideApply=true

Apply the following manifest with argo (modify name and namespace as needed)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tools-pg-pooler
  namespace: tools
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: kubernetes.io/arch
                    operator: In
                    values:
                    - amd64

This seems to work fine for me as argo patches the existing deployment controlled by the operator to add the affinity so pods are not scheduled to arm64 nodes.