Is that actually the case? Is there a serious risk that a database will be corrupted by a container crash, as the article claims? A regular crash of the computer should not be able to corrupt a database, is a container more dangerous in this regard?
Depending on the customer and the tech involved we'll do blue-green by doing a controlled rolling push of the config or image after it makes it through the dev/test cycle. Also depending on the type of tech we'll store actual data on network or host volumes.
I have run database clusters on kubernetes in production without running into this particular problem.
The current state of container orchestrators for running databases is not optimal because one size does not fit all database types like with stateless applications. One solution for this problem are coreos operators which introduce third party resources into kubernetes that are specific to the database type and contain logic to manage this specific database type on kubernetes.
Mainly that when disk say that data was written, it really was written, and that the data was written in the right order.
The danger with overlay systems is that they might not provide these guarantees, which makes database writes unsafe. Given that current overlay drivers are unstable as it is, I doubt they put any effort to enforce such guarantees.
Not exactly a database but for example with ZFS it is known that ZFS can't provide guarantees that usually provides if you run it in a VM, unless you have a hardware that supports VT-d (a.k.a. PCI pass-through) and have it enabled.
This is true for any and all file systems. ext4 can't provide those guarantees either because it's up to the hypervisor to do the right thing when the guest requests it to flush caches to disk.
ZFS just happens to have made it very explicit that it requires certain guarantees to provide the data reliability, but those same requirements exist for other file systems.
There are major issues registered with AUFS, Overlay, Overlay2 and BTRFS. It's ridiculous.