3 ms·

There are things I don't understand with Kubernetes and the "spin up containers as needed". How do you spin up different databases ? It won't sync, unless your

There are things I don't understand with Kubernetes and the "spin up containers as needed". How do you spin up different databases ? It won't sync, unless your code takes that into account... Say, I have a simple WP site running with a web, a php and a db container... What's the schema to give 2 or 3 more database container and still have visitors see the same content ? (and the databases being consistent) Set up replication ?

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 ago
  This 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 ago
  From what I understand thos is what you need kubernetes database operators for. They configure the database cluster for you.
e12e 7y ago
For complex services (maybe as simply defined as need low latency durable high-write-rate storage) - I'm not even sure if you should run it on a k8s pod. K8s offers some "services", notably storage - that afaik don't typically run "on" k8s, but "as part of" k8s. I think databases (for production use) are better off managed as services? So typically on physical hw next to the hw that runs k8s? The alternative (as mentioned here) is to guarantee local storage on same hw next to the pod running the DBs - and you'd typically want to dedicate cpu, io and ram to the db - probably dedicate physical hw to the db pod(s). Maybe k8s can take care of failing over to a follower - but I don't think that's likely to work without a "plug in" in k8s for your db of choice? Maybe someone running redshift, spanner or azul sql service have some insight? Ed: for development and testing, that's another matter. But even then I think I'd prefer "provision a new db/schema on my beefy db service" to spinning up a pod that just happens to run a db daemon.

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 ago
This 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 ago
From what I understand thos is what you need kubernetes database operators for. They configure the database cluster for you.

e12e 7y ago

For complex services (maybe as simply defined as need low latency durable high-write-rate storage) - I'm not even sure if you should run it on a k8s pod. K8s offers some "services", notably storage - that afaik don't typically run "on" k8s, but "as part of" k8s. I think databases (for production use) are better off managed as services? So typically on physical hw next to the hw that runs k8s? The alternative (as mentioned here) is to guarantee local storage on same hw next to the pod running the DBs - and you'd typically want to dedicate cpu, io and ram to the db - probably dedicate physical hw to the db pod(s). Maybe k8s can take care of failing over to a follower - but I don't think that's likely to work without a "plug in" in k8s for your db of choice? Maybe someone running redshift, spanner or azul sql service have some insight? Ed: for development and testing, that's another matter. But even then I think I'd prefer "provision a new db/schema on my beefy db service" to spinning up a pod that just happens to run a db daemon.