Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PostgreSQL 14 on Kubernetes

blog.crunchydata.com

Post reply on HN
Print view View original

31–40 of 87 posts

Re: PostgreSQL 14 on Kubernetes

#31

Post by Hamuko »

manigandham wrote: post #11
leetrout wrote: post #3

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.

>Stateful services like databases are not really a challenge anymore given recent developments in both K8S and database containerization.

People say this but my first reaction to "let's put our DB in the Kubernetes cluster" is still to take two steps backwards and prepare to run in the other direction. It really goes against all of my better instincts (and unfortunately hands-on experiences).

Re: PostgreSQL 14 on Kubernetes

#32

Post by sergioisidoro »

whazor wrote: post #27

I would like to see a comparison between this operator and the one from Zalando.

I tried both while testing things for a personal project. In my very not exhaustive user perspective, I like Crunchy better.

Zalando seems to fit the Zalando use case (not surprisingly), which is having multiple teams self-service their postgres clusters. They have a nice Web ui that is good for people who are not familiar with k8 to provision databases. However a lot of those features are a bit intrusive when you want to start a small project. The "teams" attributes are required in the clusters, for example, although you're not using them.

I ended up using Cruncy for my personal project because its a bit simpler, looked like having a bit more activity on Github, and slightly better documentation from my perspective.

Re: PostgreSQL 14 on Kubernetes

#34

Post by karolist »

alphabettsy wrote: post #15
tiew9Vii wrote: post #14

Earlier quoted context omitted.

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, Node Groups, and Node Affinity/Taints solve some of those issues.

A database is not a service well suited for ephemeral, quick scale down and scale up container workloads that K8s really excells at, and if you have nodes specifically configured to run databases and nothing else then you should simply run them there directly and not mangle K8s to replicate what will essentially be equivalent to running them there directly.

Re: PostgreSQL 14 on Kubernetes

#35

Post by dijit »

dagw wrote: post #24
leetrout wrote: post #3

Why would i want to run my database in k8s?

At least in my case, because your ops team has decided that everything that gets deployed, gets deployed in k8s (unless you have a Very! good reason not to)

Kubernetes is great but not everything fits in kubernetes, this is a bad ops team if this is the case.

Re: PostgreSQL 14 on Kubernetes

#36

Post by funcDropShadow »

alphabettsy wrote: post #15
tiew9Vii wrote: post #14

Earlier quoted context omitted.

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, Node Groups, and Node Affinity/Taints solve some of those issues.

So, the argument to deploy a database (e.g. Postgres) via Kubernetes is, that that some of the problems doing so are now solved?

Re: PostgreSQL 14 on Kubernetes

#38

Post by arianvanp »

tiew9Vii wrote: post #14
manigandham wrote: post #11

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…

Have a look at local storage provisioners. There are plenty of them

They give you raw access to storage without redundancy. Which is great if your workload on top (like https://k8ssandra.io) already is redundant. Whilst making sure workloads stick to where their data is stored

E.g. https://github.com/openebs/lvm-localpv

Re: PostgreSQL 14 on Kubernetes

#39

Post by brainwipe »

This is an excellent, well explained article. For most of the small companies I work for, database hosting is treated like a utility so we end up using RDS etc. The benefit of arranging your own k8 database setup is outweighed by the cost of maintenance. On one hand it's nice that it's one less thing to worry about, on the other I miss this kind of deep nerdery.

Re: PostgreSQL 14 on Kubernetes

#40

Post by peterthehacker »

rossmohax wrote: post #33

Best way to run database is in static pods. You'll get all the benefit of kubernetes ecosystem (monitoring, logs, inventory, access control) without any drawbacks.

You mean without a deployment or statefulset? How would you connect to the DB without a service providing a persistent DNS name?
Post reply on HN