<p>I am quite a beginner in Kuberenetes and would like to ask about some concepts related to kuberenetes pod assignment.</p>

<p>Suppose there is a deployment to be made with a requirement of 3 replica sets.</p>

<p>(1)</p>

<p>Assume that there are 4 nodes, where each of it being a different physical server with different CPU and memory.</p>

<p>When the deployment is made, how would kubernetes assgin the pods to the nodes? Will there be scenario where it will put multiple pods on the same server, while a server does not have pod assignment (due to resource considereation)?</p>

<p>(2) </p>

<p>Assume there are 4 nodes (on 4 indentical physical servers), and 1 pod is created on each of the 4 nodes.</p>

<p>Suppose that now one of the nodes goes down. How would kuberenetes handle this? Will it recreate the pod on one of the other 3 nodes, based on which one having more available resources?</p>

<p><br/>
<br/>
Thank you for any advice in advance.</p>

Patrick C.
<p>There's a brief discussion of the <a href="https://kubernetes.io/docs/concepts/scheduling-eviction/kube-scheduler/" rel="nofollow noreferrer">Kubernetes Scheduler</a> in the Kubernetes documentation.  Generally scheduling is fairly opaque, but you also tend to aim for fairly well-loaded nodes; the important thing from your application point of view is to set appropriate resource <code>requests:</code> in your pod specifications.  Just so long as there's enough room on each node to meet the resource requests, it usually doesn't matter to you which node gets picked.</p>

<p>In the scenario you describe, (1) it is possible that two replicas will be placed on the same node and so two nodes will go unused.  That's especially true if the nodes aren't identical and they have resource constraints: if your pods require 4 GB of RAM, but you have some nodes that have less than that (after accounting for system pods and daemon set pods), the pods can't get scheduled there.</p>

<p>If a node fails (2) Kubernetes will automatically reschedule the pods running on that node if possible.  "Fail" is a broad case, and can include a node being intentionally stopped to be upgraded or replaced.  In this latter case you have some control over the cluster's behavior; see <a href="https://kubernetes.io/docs/concepts/workloads/pods/disruptions/" rel="nofollow noreferrer">Disruptions</a> in the documentation.</p>

<p>Many environments will run a <a href="https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling" rel="nofollow noreferrer">cluster autoscaler</a>.  This can cause nodes to come and go automatically: if you try to schedule a pod and it won't fit, the autoscaler will allocate a new node, and if a node is under 50% utilization, it will be removed (and its pods rescheduled).  In your first scenario you might start with only one node, but when the pod replicas don't all fit, the autoscaler would create a new node and once it's available the excess pods could be scheduled there.</p>
