<p>I research about Kubernetes and actually saw that they do load balancer on a same node. So if I'm not wrong, one node means one server machine, so what good it be if doing load balancer on the same server machine. Because it will use same CPU and RAM to handle requests. First I thought that load balancing would do on separate machine to share resource of CPU and RAM. So I wanna know the point of doing load balancing on same server.</p>

<p>If you can do it on one node , it doesn't mean that you should do it , specially in production environment.</p>

<ul>
<li>the production cluster will have least 3 or 5 nodes min</li>
<li>kubernetes will spread the replicas across the cluster nodes in balancing node workload , pods ends up on different nodes</li>
<li>you can also configure on which nodes your pods land</li>
<li>use advanced scheduling , pod affinity and anti-affinity</li>
<li>you can also plug you own schedular , that will not allow placing the replica  pods of the same app on the same node</li>
<li>then you define a service to loadbalance across pods on different nodes</li>
<li>kube proxy will do the rest</li>
</ul>

<p>here is a useful read:</p>

<p><a href="https://itnext.io/keep-you-kubernetes-cluster-balanced-the-secret-to-high-availability-17edf60d9cb7" rel="nofollow noreferrer">https://itnext.io/keep-you-kubernetes-cluster-balanced-the-secret-to-high-availability-17edf60d9cb7</a></p>

<blockquote>
  <p>So you generally need to choose a level of availability you are
  comfortable with. For example, if you are running three nodes in three
  separate availability zones, you may choose to be resilient to a
  single node failure. Losing two nodes might bring your application
  down but the odds of loosing two data centres in separate availability
  zones are low.</p>
  
  <p>The bottom line is that there is no universal approach; only you can
  know what works for your business and the level of risk you deem
  acceptable.</p>
</blockquote>
