<p>Assuming this scenario:</p>
<p><strong>Service A (ClusterIP):</strong></p>
<ul>
<li>Pod1 (Image1)</li>
<li>Pod2 (Image1)</li>
<li>Pod3 (Image1)</li>
</ul>
<p><strong>Service B (ClusterIP):</strong></p>
<ul>
<li>Pod1 (Image2)</li>
<li>Pod2 (Image2)</li>
<li>Pod3 (Image2)</li>
</ul>
<p>Assuming that I have an Ingress Controller:</p>
<p>/svcA &gt; This will redirect to Service A
/svcB &gt; This will redirect to Service B</p>
<p>So my question is, the Service is still doing a Load Balancing between the pods?
What if Pod1 of Service A is busy and the request has to be attender by either Pod2 or Pod3 of Service A ??
Who is performing that Load Balancing?</p>
<p>Thanks!</p>

Jerry Santana
<p>A piece of Kubernetes infrastructure called <code>kube-proxy</code> provides load balancing for ClusterIP services (and NodePort and LoadBalancer services when called from inside the cluster).  The actual load balancing depends on the cluster configuration but it usually isn't intelligent; typical out-of-the-box setups will use either round-robin or random routing.  The section on <a href="https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies" rel="nofollow noreferrer">Virtual IPs and service proxies</a> in the Kubernetes documentation discusses this in a little more detail.</p>
<p>If the pod <code>deployment-a-pod-1</code> is so busy that it can't handle requests, a third of requests to <code>service-a</code> will time out.  If this backlog also affects the HTTP requests you're using for liveness probes, it will eventually cause the pod to restart, and any outstanding connections to that specific pod will get lost.  In both cases the client will have to retry the affected requests.</p>
