4 ms·
> I think that simplest solution is some kind of NFS server. Kubernetes can consume it as well. Isn't this asking for trouble, running MySQL on top of NFS? Al
by thunky 4y ago
> I think that simplest solution is some kind of NFS server. Kubernetes can consume it as well.
Isn't this asking for trouble, running MySQL on top of NFS?
Also a k-nube.
- vbezhenar 4y agoI 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 agoI 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.