Earlier quoted context omitted.
Poorly? Almost none. Well? Significant.
Unhelpful and arrogant. We are amateurs in the eyes of the gods.
You're right. But so am I.
PostgreSQL 14 on Kubernetes
61–70 of 87 posts
Re: PostgreSQL 14 on Kubernetes
#62Why would i want to run my database in k8s?
20 years ago people said the same thing about running DBs on virtual machines. Now almost all databases are run on VMs
But that’s really not a great comparison, is it? Running on a VM is much more like running on a plain physical node. Running on K8s implies a whole new level of management overhead, that just isn’t there on a single node system.
In this case, you should be asking “will we all be running databases in clustered mode in the future?”
I think that answer still up for debate.
Re: PostgreSQL 14 on Kubernetes
#63Running anything which depends on disk cache 'working' should not be run in a shared environment, unless your application can run arbitrarily slowly.
If I understand how it works, allocating memory to a container does not allocate memory for caching of data, and any IO done by any container can eject data from the cache, which means any IO intensive process will step on any other.
Re: PostgreSQL 14 on Kubernetes
#64Earlier quoted context omitted.
20 years ago people said the same thing about running DBs on virtual machines. Now almost all databases are run on VMs
But that’s really not a great comparison, is it? Running on a VM is much more like running on a plain physical node. Running on K8s implies a whole new level of management overhead, that just isn’t there on a single node system. In this case, you should be asking “will we all be running databases in clustered mode in the future?” I think that answer still up for debate.
containers are actually a really good fit for dbs. they do one thing and one thing only and for a really really long time without many changes.
and the answer is we will definitely be running DBs in clustered mode in the future. its not really a debate its an eventuality.
without clusters you lose on reliability and maintenance QOL improvements. without clusters its very hard to upgrade systems effectively leaving systems to stagnate and decay both in performance (Hard/Software improvements aka kernel updates or inbternal DB improvements) and reliability.
Re: PostgreSQL 14 on Kubernetes
#65The truth is Kubernetes already has all the primitives to run database or any other stateful applications. What is challenging is how to make it reliable, performant and scalable for this kind of apps. If you manage to do it properly, then it will be far less costly and manageable than any DBaaS out there. There are 2 dimensions to the problem: 1) How to easily deploy and operate a "production" DB in K8S. As the tool…
while you can -- and I've worked at shops that have -- and there are DBs like Cockroach that are k8s native... I still wouldn't. Give me a some VMs and I'll create a cluster. Sure it will be overprovisioned and such but it's a database. It needs to be solid and consistent and slow to change.
I still think it's best to allow K8s to coordinate ephermeral containers with little to no persistent storage and let the DBs be run more traditionally.
Re: PostgreSQL 14 on Kubernetes
#66Earlier quoted context omitted.
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.
K8S runs workloads across servers in a declarative fashion. Ephemeral or stateful doesn't make a difference anymore. Whatever you use to manage the nodes directly is basically what K8S provides (and more) already, so you're really just replicating effort and complexity instead.
what happens when you declare that your PG 13 cluster should now be PG 14?
I haven't yet seen good documentation on how these K8s databases handle upgrades. Additionally, they all seem very quick to stream from master to create a new node. That is great, for very, very small db's. But a 1TB db would be royal pain to do that with.
Re: PostgreSQL 14 on Kubernetes
#67what's the minimum resource requirements for a minimal 1 micro-sized table, and very low traffic? Is it in the magnitude of 100s of MB and tens of a vcore ? or .. ?
Re: PostgreSQL 14 on Kubernetes
#68The truth is Kubernetes already has all the primitives to run database or any other stateful applications. What is challenging is how to make it reliable, performant and scalable for this kind of apps. If you manage to do it properly, then it will be far less costly and manageable than any DBaaS out there. There are 2 dimensions to the problem: 1) How to easily deploy and operate a "production" DB in K8S. As the tool…
I have to ask, do you have an interest in ONDAT/StorageOS? Because you say they're a leader and yet I've never run into them, your account is two weeks old, and I see they've just started a twitter account, so it all kind of smells like a PR push.
Re: PostgreSQL 14 on Kubernetes
#69Earlier quoted context omitted.
20 years ago people said the same thing about running DBs on virtual machines. Now almost all databases are run on VMs
But that’s really not a great comparison, is it? Running on a VM is much more like running on a plain physical node. Running on K8s implies a whole new level of management overhead, that just isn’t there on a single node system. In this case, you should be asking “will we all be running databases in clustered mode in the future?” I think that answer still up for debate.
> Running on a VM is much more like running on a plain physical node.
Sure, and containers are just plain processes on a VM. The exact code that controls processes in a VM, also controls processes inside a container.
As long as the underlying data volume is reliable, it really doesn't matter whether you're running it outside of a container or not. Volumes for K8s have a come a long way since its early days.
Re: PostgreSQL 14 on Kubernetes
#70Earlier quoted context omitted.
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.
I’ll bite. Any good reading on highly available multi-region failover?
Kubernetes doesn't "failover" like that. Each cluster does it's best to keep your workloads running but stretching across multi-clusters is your responsibility. There is K8S Federation [1](previously called multicluster) which is about deploying from a single host cluster to multiple other ones, but it's still unfinished, and either way K8S doesn't know much about your application itself to be able to perform any kind of failover switch.
Usually if it's a stateless app then the solution is using a global load balancer or other networking at the edge to steer traffic to the responsive regions. Databases also tend to have their own replication and distribution strategies handled internally that should be used, along with the above mentioned networking.