3 ms·

I don't have experience with that kind of setup, so can't really comment. Kubernetes is not magic, if you're running MySQL in NFS volume, it's just mysql proces

I don't have experience with that kind of setup, so can't really comment. Kubernetes is not magic, if you're running MySQL in NFS volume, it's just mysql process running in separate cgroup with mounted NFS volume. If you think that's a bad idea, don't do that. When it comes to processes and mounts, Kubernetes just arranges things and rest is done my ordinary Linux APIs. I tried to run Postgres with ceph volume and it works for me. You can configure database to just use local storage. Of course if your server will die, your database will die, so probably you will want some kind of cluster setup or be ready to restore database from backup if that happens. Or you can start with simple setup and migrate to something more complex in the future.

thunky 4y ago
I hadn't heard about k8s "local storage". IIUC this fixes each pod to a single node, so the potential benefits of k8s can't be fully realized. It seems that clustering could still be achieved by running muliple instances across multiple nodes, each with local storage. I might still prefer this to having to manage NFS and any difficulties that might come from using MySQL with remote disks. It just seems like k8s is coercing people to do things that they normally wouldn't do: MySQL on NFS, Postgres on Ceph, etc. In this case, OP just wants to "kubernetify my run of the mil lamp app" and is now being pointed towards NFS, Ceph, etc. I can't help but wonder if the juice is worth the sqeeze. Especially for services like databases that for most people probably don't really require dynamic provisioning or orchestration.