11–20 of 87 posts
Why would i want to run my database in k8s?
I think when I see tutorials like this all I see is the large bill I’ll be receiving $$$, can articles like these include costs??
A small database might be just $5 per month if its a thin slice of a big shared Kubernetes pie.
Or it could be $500K per month if it's a huge set of replicated server storing petabytes, replicated for dev, test, and prod.
Why would i want to run my database in k8s?
Because kubernetes is a fantastic platform that provides a lot of node and app management functionality out of the box. Stateful services like databases are not really a challenge anymore given recent developments in both K8S and database containerization.
What does Kubernetes offer in this scenario?
I'm still hesitant to run things like DB's on K8's but have absolutely no problems running cloud native apps on K8's which can run ephemerally, be bin packed and only needing compute as all state is external to where the app is being executed.
Earlier quoted context omitted.
Because kubernetes is a fantastic platform that provides a lot of node and app management functionality out of the box. Stateful services like databases are not really a challenge anymore given recent developments in both K8S and database containerization.
With a database I generally want to have it on its own dedicated host with fast NVME drives, memory, cpu etc, maybe some OS specific system level configuration options for performance etc. I don't want to binpack it on a cluster of nodes each contending for system resources. Also RDBMS databases are not really designed to be ephemeral/elastic, they are stateful/persistent by nature. What does Kubernetes offer in this…
Why would i want to run my database in k8s?
a) run your stateful services (such as Postgres) on the same orchestration system
b) choose a second orchestration system (often a more "traditional" infrastructure provisioning system like Chef/Puppet/Ansible/SaltStack) that will only manage your stateful services, and deal with the care & feeding & mental overhead of having two things that do fairly similar jobs and need to interact with each other (because of course your k8s-hosted stateless services need to be able to look up Postgres in DNS)
(option C would be to use a managed service like RDS...but options A and B assume you've already made a decision, for whatever reason, to run the stateful services yourself)
Why would i want to run my database in k8s?
Because kubernetes is a fantastic platform that provides a lot of node and app management functionality out of the box. Stateful services like databases are not really a challenge anymore given recent developments in both K8S and database containerization.
I've faced so many issues with the CSI driver which doesn't attach/deattach properly when you modify anything on the Statetfulset.
Additionally, you need to pin your DBs ("statefulset workloads") to certain Nodes based on the AZs since a block storage like an EBS cannot really be attached from Zone 1 to Zone 2 automatically.
Based on these limitations, I dont really see any utility/usefulness in running a DB on K8s. I get all of the other niceties that K8s offers, but here it makes the Ops work more complex than desired.
Earlier quoted context omitted.
Because kubernetes is a fantastic platform that provides a lot of node and app management functionality out of the box. Stateful services like databases are not really a challenge anymore given recent developments in both K8S and database containerization.
With a database I generally want to have it on its own dedicated host with fast NVME drives, memory, cpu etc, maybe some OS specific system level configuration options for performance etc. I don't want to binpack it on a cluster of nodes each contending for system resources. Also RDBMS databases are not really designed to be ephemeral/elastic, they are stateful/persistent by nature. What does Kubernetes offer in this…
- StatefulSets mean that K8s scheduling is aware that the workload is stateful and the auto-attach of drives works fantastically in my experience.
- NodeTaints/Tolerances and workload anti-affinities between workloads mean that you can very easily say “this workload runs on nodes with these features/labels” and “don’t run workload replicas on the same node” and “don’t run other workloads on the same node as this workload. Node groups on things like AWS EKS also make it really easy to get autoscaling groups of nodes with specific hardware.
cant think of a scenario where you need to query multiple databases in same query! Nice demo, but deploying it all in a cluster is distracting. Maybe do your next demo with docker-compose!
You're suggesting that next time they should demonstrate Postgres on Kubernetes without the distracting Kubernetes part?
I always thought it's better to host distributed database, like Cockroachdb and Yugabytedb, in multiple kubernetes clusters. Just in case one of the cluster goes down.
A K8S cluster is already designed to be highly available and self healing. Stretching across clusters is usually a special case of scaling across datacenters/regions and brings a lot more overhead and complexity.