RollingUpdate of Pooler stuck due to low number of nodes

[haslersn]

postgres-operator version: registry.opensource.zalan.do/acid/postgres-operator:v1.7.0

Introduced in #1464: When using

• pod_antiaffinity_topology_key: "kubernetes.io/hostname",
• PostgreSQL cluster with spec.connectionPooler.numberOfInstances: 3,
• K8s cluster with 3 nodes,

the pooler Deployment cannot be updated. The update strategy is RollingUpdate and it attempts to create a fourth instance before terminating any instance. However, the fourth instance cannot be scheduled due to the antiaffinity.

Possible solution

I see two possible solutions, but maybe there are also other solutions:

• Add an option to configure the pooler Deployment's spec.strategy.rollingUpdate.maxUnavailable setting.
• Use preferredDuringSchedulingIgnoredDuringExecution instead of requiredDuringSchedulingIgnoredDuringExecution: for poolers.

[yevon]

The problem with this is the deployment config with the pooler config:

rollingUpdate:
  maxSurge: 25%
  maxUnavailable: 25%

This only works it you have at least 4 pods. Check kubernetes docs as they state this behaviour:

https://kubernetes.io/es/docs/concepts/workloads/controllers/deployment/

The problem with this config is that if you have less than 4 nodes it won't work as it will be 0. Because maxUnavailable of 2 nodes is 0.5 nodes that is round to 0. The same with maxSurge, it will be 0 so the rolling upgrade will be stuck forever as you are not allowing more nodes or less than 3.

[FxKu]

The affinity used for poolers (and database pods) can now be set to preferredDuringSchedulingIgnoredDuringExecution. I hope this solves your issues.