I could add to that topic that we’ve developed a system together with LXC, which we’ve integrated into CRI to manage stateful services in a robust and performant way. Kubernetes itself is not a show stopper for handling data. The container layer itself is more or less implemented in a good way to handle data (i.e. a restart of docker in case of updating the docker daemon).
The stateless implementation of docker in case of updating stuff is also a bit difficult because a production SQL server shouldn’t just stop in case that one file has to be updated in the container. So for state it makes sense to handle state in a good way. That is another reason to choose a container engine which is able to handle state.
However, we observed that a lot of interfaces/assumptions exists in Kubernetes around docker. For example we saw, that the CRI doesn’t contain an interface to transport a hostname in case of host networking. We’ve opened an issue on Github for that.
We plan to open some parts of our development if there is interest around.