This is our finalized architecture for a PostgreSQL failover scenario across two data centers. This will be provided as a suggested approach for our enterprise on-premise customers who want to implement high availability (HA) for PostgreSQL with our product.
Our current concern is that maintaining the above architecture is quite difficult for our customers, as it requires managing each service across multiple nodes. Because of this, we are planning to explore the Percona PostgreSQL Operator.
Please confirm:
Whether the above architecture is possible in on-premise using the Percona PostgreSQL Operator
Whether there are any drawbacks to using a Kubernetes operator instead of separate VMs
Is this Kubernetes operator is only best for online Kubernetes platforms or it also works well on free opensource on-premise Kubernetes flavours.
Our current concern is that maintaining the above architecture is quite difficult for our customers
If simplification is the objective, I would suggest to engage experts to reduce the complexity of the topology. for example, some of the components may not be required for all environments.
if you want to migrate to Percona operator, Percona operator allows pgBackRest backup to be restored to K8s cluster. You may please refer to the options presented in the Percona blog.
Regarding your questions.
Percona Operator internally uses same Patroni to achieve HA and pgBackRest for taking backup. So the architecture will be very similar, but instead of ETCD, it uses K8s APIs.
The viability of K8s operator depends on specific use cases. It can be hosted on local on-premise K8s cluster. I would suggest you to give a try with test clusters.
