Study the use of startup probes in patroni pod / Liveness probe alternative
Problem to solve
Liveness probes can be dangerous for an application like PostgreSQL, when there is an active cluster with many data, if you want to increase the number of replicas, patroni starts to replicate to the new node using streaming replication, until the replica is active, patroni reports the pod as unhealthy.
Further details
The current Liveness probe kills the pod in a loop when there is a replication happening, since the replication never ends because it's reported as unhealthy by patroni it cause a loop where Postgres tries to catchup the replica and Kubernetes kills the pod since it's not ready.
A startup probe allow more fine grained control in the pod lifecycle. The other alternative is to avoid the use of the liveness probe and or use a completely different check.
Risks
The really big issue with startup probes is that are new in Kubernetes, introduced as a an alpha feature in Kubernetes 1.16, and since we aim to support older and more common Kubernetes versions it's probably not a solution right now.