Let me make a statement first: I'm new to Kubernetes, please take it easy if I'm asking wrong questions.
Ok, here is what I'm gonna do. I'm planning to build a Kubernetes for my project using some physical machines.
I have 1 server for master and 2 worker nodes. My service dockers (pods) will be allocated by Kubernetes master, they will need storage for the database (MySQL).
After searching around, I came up with a solution of Persistent Volume, but I don't want to use those online cloud services out there such as Google Cloud or Azure Cloud, etc. It leads me to another solution - Local Persistent Volume (LPV), this is where I stuck currently.
The problem with LPV is it's attached with a specific node, so I wouldn't be able to replicate (backup) the database on other nodes, if something happens to this node, or something wrong with the physical disk, I'm gonna lose all the databases, right?
The question is, are there any solutions to set up replication on the database using Local Persistent Volume? For example, I have a database on Node 1, and a backup version on Node 2, so when Node 1 is not available, the pods will mount to the backup database on Node 2.
Thanks in advance!
You can deploy the database as statefulset using local volumes on nodes.Just create the volumes and put them in a StorageClass
For backup , you need to setup the replication on the database level ( not volume level ) to some other cluster /other database instance running somewhere else/or on some other cluster.
Pod failures are handled by kubernetes anyway , it will restart the pod if goes unhelathy.
Node failures can't be handled in statefulset ( one node can't replace another , in other words , in statefulset a pod will not be restarted on other node , kubernetes will wait for node to come back )
If you are going for simple single pod deployement rather than statefulset , you can deploy the database as single pod and another instance as single pod and use node selector to run those on different nodes , then setup the replication from one instance to another instance on database level , and configure your client app to failover to fallback instance in case the primary is not available , this needs to be synchronous replication.
Links: