RollingUpdate strategy does not seem to work with leader election #419

RollingUpdate strategy does not seem to work with the default enabled leader election. The old instance keeps the lease claimed, and the new instance has a failing readiness probe until it can claim the lease. This was discovered while testing the helm chart pull request, but I believe the same should be happening with the kustomize install since it also uses rolling update strategy by default.

This is what I observe when triggering a rollout restart operation:

The readiness probe is unhealthy until the new pod gets the lease:

{"level":"info","ts":"2025-06-24T15:26:01.370038527Z","msg":"starting manager"}
{"level":"info","ts":"2025-06-24T15:26:01.37156252Z","msg":"starting server","name":"health probe","addr":"[::]:8081"}
{"level":"info","ts":"2025-06-24T15:26:01.372609226Z","msg":"attempting to acquire leader lease cloudnative-postgres/822e3f5c.cnpg.io..."}

Because the readiness probe of the new pod doesn't become ready until it can get the lease, there aren't sufficient ready pods and kubernetes doesn't send the shutdown signal to the old leader. Because the old leader doesn't get a shutdown signal, it has no reason to drop the lease claim.

This seems like a bug in plugin-barman-cloud leader election, but means that rolling update currently doesn't properly work as a default. Leader election does work in the cloudnative-pg operator, so something in the leader election works differently in the barman cloud plugin

Originally posted by @rouke-broersma in cloudnative-pg/charts#598 (comment)