> This is the exact opposite of what Kubernetes seek to provide
Not true. You can have dedicated machines for your db instances, check out 1. node affinity 2. Statefulsets.
Statefulsets are designed to provide consistency (no "split brain"), stable network identity ("at a consistent address"), stable storage identity ("and that the data directory will be available to the server as soon as it starts up"). Those features are beta but it's a matter of time (hardening and the likes) before we tut them stable.
> why would you?
For all the same reasons you would run any other workload on the same platform.
The reason to run any other workload on Kubernetes is to dynamically schedule your containers across a cluster of anonymous hardware resources, and to provide automatic monitoring, recovery, and control of those containers when certain events occur. The goal, essentially, is to abstract the hardware/system-level element from the deployment element. That's all well and good, but applications that make certain architectural assumptions do not lend themselves well to random scheduling across an anonymous array of system resources. Databases are absolutely among that class of applications, as are many other application types (which are now called "stateful" applications).
For k8s to work well for an application, that application has to be anonymous, without any masters or controllers. It has to be able to tolerate the sudden vaporization of any member. It has to be willing and able to share host hardware with any number of other services, including some which may be bad neighbors/CPU hogs, and it has to be content to be rescheduled in the event that a node goes down, that a pod is killed to ease the transition, etc. Databases fail on virtually every point of this.
If the database and Kubernetes start from opposite design paradigms, why does it make sense to run a database inside Kubernetes? I am still not getting it. `kubectl delete pod/my-postgres-pod` is not a smart thing; you don't want any of that scheduling magic that Kubernetes provides.
At most you would want Kubernetes to tell you that your database is failing health checks and execute the STONITH process to failover to replica, but you hardly need Kubernetes if all you care about is process monitoring.
So can you elaborate on the reasons? Databases are simply not designed for this kind of infrastructure and I see no value in trying to pretend they are. Isn't this the reason that CockroachDB exists, so that people can finally run their DBs in something like Kubernetes without endless headaches?
I think it would be very interesting to analyze the stability and performance features of a PgSQL k8s deployment, PgSQL VM deployment, and PgSQL bare metal deployment. The only issue is that you can't expect the failures to be open with their data.
Not true. You can have dedicated machines for your db instances, check out 1. node affinity 2. Statefulsets.
Statefulsets are designed to provide consistency (no "split brain"), stable network identity ("at a consistent address"), stable storage identity ("and that the data directory will be available to the server as soon as it starts up"). Those features are beta but it's a matter of time (hardening and the likes) before we tut them stable.
> why would you?
For all the same reasons you would run any other workload on the same platform.