Self-hosting a high-availability Postgres cluster on Kubernetes
ryan-schachte.com
Self-hosting a high-availability Postgres cluster on Kubernetes
1–10 of 92 posts
Re: Self-hosting a high-availability Postgres cluster on Kubernetes
#2My holiday project was doing another pass at my Homelab Kubernetes cluster, part of which involved switching to a proper operator to manage Postgres. Coincidentally, I setup cloudnative-pg (https://github.com/cloudnative-pg/cloudnative-pg) yesterday.
Re: Self-hosting a high-availability Postgres cluster on Kubernetes
#3My holiday project was doing another pass at my Homelab Kubernetes cluster, part of which involved switching to a proper operator to manage Postgres. Coincidentally, I setup cloudnative-pg ( https://github.com/cloudnative-pg/cloudnative-pg ) yesterday.
Any reason you landed on that Operator compared to what OP is using (Zalando)?
Re: Self-hosting a high-availability Postgres cluster on Kubernetes
#4Just like with cloud providers, it seems to me like with kubernetes, it is not a matter of if but when orchestration problems will arise. Specially in this case of hosting databases, a composition of provisioning complexities (db operational complexities on top of k8s operational complexities) is really scary.
Is there any way to overcome hidden complexity biting your hand other than studying k8s extensively?
Re: Self-hosting a high-availability Postgres cluster on Kubernetes
#5Just like with cloud providers, it seems to me like with kubernetes, it is not a matter of if but when orchestration problems will arise. Specially in this case of hosting databases, a composition of provisioning complexities (db operational complexities on top of k8s operational complexities) is really scary. Is there any way to overcome hidden complexity biting your hand other than studying k8s extensively?
This kind of resilience is a form of art, and it's also kind of a full-time job.
I would not advise trying this for a "side project at work".
Generally we all agree that we move to the cloud and it's "fully managed". If it goes down - that's the price we pay.
If you have to ask the question "what if the RDS goes down", then you are really in a different universe.
That last guarantee of uptime requires a ton of work, testing, and money, because you are all the way up and to the right on the curve of diminishing returns.
Re: Self-hosting a high-availability Postgres cluster on Kubernetes
#6Just like with cloud providers, it seems to me like with kubernetes, it is not a matter of if but when orchestration problems will arise. Specially in this case of hosting databases, a composition of provisioning complexities (db operational complexities on top of k8s operational complexities) is really scary. Is there any way to overcome hidden complexity biting your hand other than studying k8s extensively?
Not really. Those are two areas you need to really understand when things go south.
In Kubernetes you "solve" a lot of application complexity by abstracting it into things like Helm Charts or Operators. It's fun and easy to use operators to deploy databases, monitoring, mesh, minio... This does not make complexity disappear, it just abstracts it by creating another layer with an interface (k8s API) you may be more familiar with.
Whole Kubernetes in practice is adding more and more layers on top of it. All those layers/tools are usually amazing but soon you need some real k8s skills AND some app skills to handle even unavoidable scenarios like ... upgrades.
That's why it's so confusing sometimes and has such diverse opinions on. There aren't many environments that run vanilla cluster...
Re: Self-hosting a high-availability Postgres cluster on Kubernetes
#7My holiday project was doing another pass at my Homelab Kubernetes cluster, part of which involved switching to a proper operator to manage Postgres. Coincidentally, I setup cloudnative-pg ( https://github.com/cloudnative-pg/cloudnative-pg ) yesterday.
Any reason you landed on that Operator compared to what OP is using (Zalando)?
Honestly no, it's mostly due to inexperience with operators and not really understanding what the "best" way to find operators is. I did also look at the Crunch Data one (I was having some issues setting that one up), but didn't even find Zalando during my search.
OperatorHub is currently the main resource I use, but GitHub stars aren't exposed in the search so I have been looking at the "Capability Level" chart and checking for Github popularity when I find one with the feature support I want.
I'm facing this exact same issue now when trying to find an operator for Redis. I am not sure if I am just missing out on the "right" option by limiting myself to Googling and Operator Hub and looking for the one with the most Github stars, so I am open to tips.
Re: Self-hosting a high-availability Postgres cluster on Kubernetes
#8once upon a time I set up an elastic search cluster in kubernetes
after a lot of tweaking I made it so that the pods would be as big as the underlying hardware nodes. one pod one node. once that was working I realized that I was using the wrong tool for the job.
the kubernetes tooling added nothing but complexity. needless to say I let it run like that having had wasted about a week getting it to work
Re: Self-hosting a high-availability Postgres cluster on Kubernetes
#9My holiday project was doing another pass at my Homelab Kubernetes cluster, part of which involved switching to a proper operator to manage Postgres. Coincidentally, I setup cloudnative-pg ( https://github.com/cloudnative-pg/cloudnative-pg ) yesterday.
I'm the founder of OnGres [1] the company behind StackGres [2]. I'd love to hear your feedback if you'd be interested in also trying StackGres. It's one of the most feature-full operators available, has a complete Web Console and REST API and supports close to 200 extensions.
Hope it would be interesting for you.
[1]: https://ongres.com [2]: https://stackgres.io
Re: Self-hosting a high-availability Postgres cluster on Kubernetes
#10Is Kubernetes still hard in 2024?