3 ms·
To tackle this issue in Kubernetes (specifically for a db), I have created persistent volume claims that are mounted across replicas in a db deployment, with th
by usui 7y ago
To tackle this issue in Kubernetes (specifically for a db), I have created persistent volume claims that are mounted across replicas in a db deployment, with the permission of multiple readers but only one writer. If we know that Postgres stores all its data in /var/x, then we can mount /var/x in all replicas as a shared volume.
In terms of the point related to taking into account in your application, as long as you have all the db replicas under one umbrella as a deployment/service, then having one endpoint for the db is fine and it is no concern of the application.
Keep in mind I am still learning Kubernetes, but this is what I have done to scale up separate back end components. Are there any objectionable/wrong practices being done?
- q3k 7y agoThis is not the right approach. First, ReadWriteMany implementations (which depend on your cluster) might not guarantee the sort of POSIX filesystem consistency that databases expect. Second, does Postgres in read-only replica expect to be run on a read-only, possibly-changing volume? What's the consistency model then? The standard way of doing this is to run a single postgres instance on a single PVC/PV (that replicates across the cluster anyway), letting the cluster move the pod if it dies. In addition, you can run read-only postgres replicas for some semblance of read-only HA while the master reschedules on failure. You can also go deeper into faster failover mechanisms (without having the k8s scheduler in the hot path of that) using any of the tons of postgres HA systems.
- aliswe 7y agoFrom what I understand thos is what you need kubernetes database operators for. They configure the database cluster for you.