> the default storage options did not support ReadWriteMany for Block and Object Storage, which were necessary for using my database Postgres.
Postgres does not require ReadWriteMany volumes.
> To better understand this, when I created multiple replicas, the same database could not be accessed by all the replicas. Only one at a time could access the database.
Assuming you mean multiple replicas accessing a single postgres database, this should not be a problem. I can't think of any networked database that prevents multiple clients from concurrently connecting. Postgres even has MVCC to allow multiple concurrent changes to the same record.
The architecture diagram towards the end of your blog post shows multiple subdomains, each with their own database. Each of these should be using their own RWO volume, not a single ReadWriteMany volume; that's a good way to cripple your ability to scale.
CNPG is my preferred way to manage postgres clusters on Kubernetes.
Postgres does not require ReadWriteMany volumes.
> To better understand this, when I created multiple replicas, the same database could not be accessed by all the replicas. Only one at a time could access the database.
Assuming you mean multiple replicas accessing a single postgres database, this should not be a problem. I can't think of any networked database that prevents multiple clients from concurrently connecting. Postgres even has MVCC to allow multiple concurrent changes to the same record.
The architecture diagram towards the end of your blog post shows multiple subdomains, each with their own database. Each of these should be using their own RWO volume, not a single ReadWriteMany volume; that's a good way to cripple your ability to scale.
CNPG is my preferred way to manage postgres clusters on Kubernetes.