News for hackers. Stuff that matters.
Re:Homelab: Running Postgres on Kubernetes by jauntywundrkind on Tuesday January 02, 2024 @01:19PM (#38844923)
Is the complexity better or worse than alternatives? What are the alternatives?

People use complexity as a boogieman to justify throwing together their own really wild chaotic & only so-so tested "simple" alternatives all the time.

To me, this feels like a modern wonder. We have layers of responsibility. Many people operate Kubernetes clusters already for all kinds of reasons. It provides a powerful broad base. Now on top of that, we can operate Postgres, with a very smart failover system that's super well tested & broadly used, that leverages this competent starting place.

What are the Fears Uncertainties and Doubts you have that make you scared about composition? What would help address specific concerns? To me, this division of responsibilities & use of consistent platform for a variety of needs feels like a huge win.

People love "simple" options but they're not. Run naked through the woods like savages option has appeal, but just getting started keeps adding up:

Sure, just add some bash scripts for some wal backups that go off-site. Easy! Install pgbouncer like one does, just a quick install, point it at the right systems. Setup some replication. Install and configure more kind of hairy software to make it HA. Configure some TLS cert yourself to not send naked traffic over wire. Add monitoring!

Then operationally, how quickly do you think you'll be able to fail over (with ogbouncer staying ok), failback, do an upgrade, add more replicas, lose a replica? Can you rotate cert reliably in a timely fashion? Can your replacement? How well did you document everything? Will you have all the monitoring you need when incidents start coming in, or did you just spitball a couple metrics into place?

The alternatives, in my view, are obviously bad. You can do them. Either cheaply with risk or industriously with effort & applied-talent. But having cohesive autonomic systems at our back that try to help, that can faultlessly do many common tasks with perfect accuracy (across unimaginable numbers of systems, with perfect consistency, in record time): that feels like a massively better place in the universe, one that I don't get why so many people kick scream & drag against. Rarely are their arguments well elaborated ("scary"), and their counter-suggestions feel like they massively underrated how multi-faceted & carefully connected production systems are, for good reason, and how hard it can be to remember to not forget to change X when you do Y.

Re:Homelab: Running Postgres on Kubernetes by marcosdumay on Tuesday January 02, 2024 @01:50PM (#38845358)
> What are the alternatives?

Installing the Postgres on the computer, or on a VM.

Really, just the fact that some people keep asking this question is enough to question everything else they say. The alternatives are obvious.

Re:Homelab: Running Postgres on Kubernetes by seanhunter on Tuesday January 02, 2024 @02:09PM (#38845631)
Exactly. The way people successfully did HA and scalability on databases for more than 20 years before Kubernetes existed.
Re:Homelab: Running Postgres on Kubernetes by p_l on Wednesday January 03, 2024 @04:18AM (#38852146)
With a bunch of hand crafted, hairy code to link the necessary features like fail over, backups, PITR, clustering.

I know, I did all of that.

Which is why I punt that effort to a k8s operator these days, because at the end of the day it does everything I did manually plus makes it easier for me to spin a new database that has WAL shipping and backups to different location.

Re:Homelab: Running Postgres on Kubernetes by seanhunter on Wednesday January 03, 2024 @10:20AM (#38855083)
If you're punting to an operator why k8s? There are lots of managed database providers and if they're managing it, then k8s (or not) is an implementation detail for them to worry about.
Re:Homelab: Running Postgres on Kubernetes by dilyevsky on Wednesday January 03, 2024 @12:36PM (#38856922)
Lots of various reasons. Performance, cost, compliance, and reliability are the ones I've personally seen.
Re:Homelab: Running Postgres on Kubernetes by jauntywundrkind on Wednesday January 03, 2024 @12:46PM (#38857073)
These are each specific DB-as-a-services. Instead of sinking my time into learning something universal & competent & capable at many things (Kubernetes) now I'm investing in learning & using a niche service, that I won't have fine control over & whose limits might only be clear down the road. That's a risk.

Sure the dbaas might have superb autoscing and reliability. It may or may not have good OpenTofu/terraform providers available, or other custom niche deployment tools one would need to pick up & adapt.

Same questions as roughing it hacking together pg yourself, except now you have no power. Is observability going to be up to snuff? When performance problems come, how are you going to feel when you discover that analyst techniques a and b work fine but c and d can't be done because you are on managed service that doesn't actually give you full access to the db?

Costs can also add up, and are hard to predict. If you have a managed service, you'll be using a lot more network, which often has some cost (also some latency too). This isn't for everyone, but Kube makes it easy to start with anything (ex: RPi) and scale out. Works with hosted hardware with some local SSD, or I can get a 16-core 7950X and a bunch of gen 5 nvme drives and a fraction of a terabyte of ram for <$2000 and that'll scale me to godlike levels. Whereas I'll keep paying for something hosted.

I think it's so so ideal to have a reliably capable universal autonomic computing later underfoot. Most of the backend has had special specific answers to each question, each problem. We have been disjointed. Kubernetes provides a platform applicable to a vast range of workloads, where yes you need to tune and build different clusters for different workloads, but where the skills transfer much more readily. Everyone in Kubernetes knows how to ship resources definitions/manifests, and that base knowledge is all you need to learn to start consuming services - any services - on Kubernetes. Skill transfer is immediate. Having universal patterns (the API server), backed by autonomic operators making & keeping these resources real: it's so much better than the thousand different paths road of technology we've been on until now.

Re:Homelab: Running Postgres on Kubernetes by p_l on Wednesday January 03, 2024 @03:01PM (#38859044)
Because I'm not interested killing both performance (connecting to database over open internet), my opex (hello cloud bills!), and violating customer trust (one of the reasons they pay me is because they do not want to trust American cloud vendors), just so I can have slightly smaller complexity.