[eloff]

I downvoted you because of that whole conspiracy theory you tacked onto the end of your post.

But I fully agree that kubernetes and containers are not well suited to running production databases. In theory they could achieve parity with a dedicated machine or VM, but they're still a long ways from that - and it makes it very easy to lose your data. I was recovering a database where the persistent volume wasn't setup right and the container got killed and restarted. It was just before the holidays and it was a nightmare because everyone was on vacation.

Yeah you could get into that kind of problem with a VM or dedicated machine, but the bar is a lot higher, you'd need some kind of hardware failure. Kubernetes makes it really easy to shoot yourself in the foot when running databases.

[alexandre_m]

"I was recovering a database where the persistent volume wasn't setup right and the container got killed and restarted."

In other words, your database application was using scratch storage instead of persistent volumes?

What this anecdote shows is that the developers or admins responsible to setup the database didn't do it properly.

Also, testing failures and data recovery should be your priority before going to production.

I don't see how you could blame that on software.

[eloff]

Not 100% sure that it was using scratch, but something went wrong with the persistence.

The point is not to say it wasn't human error - clearly it was, but it's an error that wouldn't have been as easy to make without kubernetes. There's a cost to running a database on k8s that largely people ignore. That's before you start talking about backups and recovery which also get harder and require more manual work with more potential for error.