<p>This is not a current practical issue, but a theoretical question. Assume K8S worker nodes <em>N1,N2,N3..Nn</em> are actually virtual machines on physical hosts <em>H1,H2,H3</em> such that <em>N1</em> and <em>N2</em> are currently on <em>H1</em>. When I want to schedule 5 instances of my pod <em>P1</em>, is there any awareness in K8S about the underlying physical host <em>H1</em>? Or is it possible that all 5 instances could be scheduled on <em>N1</em> and <em>N2</em> - resulting in all 5(<em>P1</em>) been on <em>H1</em>?</p>

aaaaarrrgghhh
<p>First of all, let's say "no". In case of "bare metal" (or VMs above bare metal) The Kubernetes "knows" only about his nodes (etcd, master, worker) and doesn't know anything about physical host, where VMs are located. But, you can label your nodes with some key/value pairs, which will ensure that this VM belongs to a physical host.</p>

<p>Secondly, let's say "yes". How any deployments of pods will be scheduled to nodes - is a k8s <em>scheduler</em>'s task, which is a part of k8s master's <em>control plane</em>. <em>Default scheduler</em> has got an algorithm how to detect the most appropriate k8s node for deploying. So, theoretically H1 could  host all 5 instances of you application.</p>

<p>Good news that it's really unlikely. Moreover, the Kubernetes provides you an ability to create your own <em>custom scheduler</em> with your own logic for scheduling and use it only for specific deployments. That's why it's hard to believe there will be case for scheduling you could not be able to resolve.</p>

<p>P.S: actually, k8s scheduling - is a too large subject to describe in a nutshell. Sufficient time should be allocated for the examination of your cases. Try to start from reading "kubernetes advance scheduling":
<a href="https://kubernetes.io/blog/2017/03/advanced-scheduling-in-kubernetes/" rel="nofollow noreferrer">https://kubernetes.io/blog/2017/03/advanced-scheduling-in-kubernetes/</a></p>

<p>Sure, it'll will help you to go forward. Good luck!</p>
