<p>I executed a scenario where I deployed Microsoft SQL Database on my K8s cluster using PV and PVC. It work well but I see some strange behaviour. I created PV but it is only visible on one node and not on other workers nodes. What am I missing here, any inputs please?</p>

<p>Background:</p>

<p>Server 1 - Master</p>

<p>Server 2 - Worker</p>

<p>Server 3 - Worker</p>

<p>Server 4 - Worker</p>

<p>Pod : "MyDb" is running on Server (Node) 4 without any replica set. I am guessing because my POD is running on server-4, PV got created on server four when created POD and refer PVC (claim) in it.</p>

<p>Please let me know your thought on this issue or share your inputs about mounting shared disk in production cluster. </p>

<p>Those who want to deploy SQL DB on K8s cluster, can refer blog posted by Philips. Link below,</p>

<p><a href="https://www.phillipsj.net/posts/sql-server-on-linux-on-kubernetes-part-1/" rel="nofollow noreferrer">https://www.phillipsj.net/posts/sql-server-on-linux-on-kubernetes-part-1/</a> (without PV)</p>

<p><a href="https://www.phillipsj.net/posts/sql-server-on-linux-on-kubernetes-part-2/" rel="nofollow noreferrer">https://www.phillipsj.net/posts/sql-server-on-linux-on-kubernetes-part-2/</a> (with PV and Claim)</p>

<p>Regards,
Farooq</p>

<hr>

<p>Please see below my findings of my original problem statement.
Problem: POD for SQL Server was created. At runtime K8s created this pod on server-4 hence created PV on server-4. However, on other node PV path wasn't created (/tmp/sqldata_.</p>

<ul>
<li>I shutdown server-4 node and run command for deleting SQL pod (no replica was used so initially).</li>
<li>Status of POD changed to "Terminating" POD</li>
<li>Nothing happened for a while. </li>
<li>I restarted server-4 and noticed POD got deleted immediately. </li>
</ul>

<p>Next Step: 
- I stopped server-4 again and created same pod.
- POD was created on server-3 node at runtime and I see PV (/tmp/sqldata) was created as well on server-3. However, all my data (example samples tables) are was lost. It is fresh new PV on server 3 now.</p>

<p>I am assuming PV would be mounted volume of external storage and not storage/disk from any node in cluster. </p>

<blockquote>
  <p>I am guessing because my POD is running on server-4, PV got created on server four when created POD and refer PVC (claim) in it.</p>
</blockquote>

<p>This is more or less correct and you should be able to verify this by simply deleting the Pod and recreating it (since you say you do not have a ReplicaSet doing that for you). The <code>PersistentVolume</code> will then be visible on the node where the Pod is scheduled to.</p>

<p>Edit: The above assumes that you are using an external storage provider such as NFS or AWS EBS (see <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes" rel="nofollow noreferrer">possible storage providers</a> for Kubernetes). With <code>HostPath</code> the above does NOT apply and a PV will be created locally on a node (and will not be mounted to another node).</p>

<p>There is no reason to mount the <code>PersistentVolume</code> also to the other nodes. Imagine having hundreds of nodes, would you want to mount your <code>PersistentVolume</code> to all of them, while your Pod is just running on one?</p>

<p>You are also asking about "shared" disks. The <code>PersistentVolume</code> created in the blog post you linked is using <code>ReadWriteMany</code>, so you actually can start multiple Pods accessing the same volume (given that your storage supports that as well). But your software (a database in your case) needs to support having multiple processes accessing the same data.</p>

<p>Especially when considering databases, you should also look into <a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">StatefulSets</a>, as this basically allows you to define Pods that are always using the same storage, which can be very interesting for databases. Wherever you <a href="https://cloud.google.com/blog/products/databases/to-run-or-not-to-run-a-database-on-kubernetes-what-to-consider" rel="nofollow noreferrer">should run or not run databases on Kubernetes</a> is a whole different topic...</p>
