<p>For a sample microservice based architecture deployed on Google kubernetes engine, I need help to validate my understanding :</p>
<ol>
<li>We know services are supposed to load balance traffic for pod replicaset.</li>
<li>When we create an nginx ingress controller and ingress definitions to route to each service, a loadbalancer is also setup automatically.</li>
<li>had read somewhere that creating nginx ingress controller means an nginx controller (deployment) and a loadbalancer type service getting created behind the scene. I am not sure if this is true.</li>
</ol>
<blockquote>
<p>It seems loadbalancing is being done by services. URL based routing is
being done by ingress controller.</p>
<p>Why do we need a loadbalancer? It is not meant to load balance across multiple instances. It will just
forward all the traffic to nginx reverse proxy created and it will
route requests based on URL.</p>
</blockquote>
<p>Please correct if I am wrong in my understanding.</p>

inaitgaJ
<p>A Service type <code>LoadBalancer</code> and the <code>Ingress</code> is the way to reach your application externally, although they work in a different way.</p>

<p><a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="noreferrer">Service:</a></p>

<blockquote>
  <p>In Kubernetes, a Service is an abstraction which defines a logical set of Pods and a policy by which to access them (sometimes this pattern is called a micro-service). The set of Pods targeted by a Service is usually determined by a <a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/" rel="noreferrer">selector</a> (see <a href="https://kubernetes.io/docs/concepts/services-networking/service/#services-without-selectors" rel="noreferrer">below</a> for why you might want a Service <em>without</em> a selector).</p>
</blockquote>

<p>There are some types of Services, and of them is the <code>LoadBalancer</code> type that permit you to expose your application externally assigning a externa IP for your service. For each LoadBalancer service a new external IP will be assign to it.
The load balancing will be handled by kube-proxy.</p>

<p><a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" rel="noreferrer">Ingress:</a></p>

<blockquote>
  <p>An API object that manages external access to the services in a cluster, typically HTTP.
  Ingress may provide load balancing, SSL termination and name-based virtual hosting.</p>
</blockquote>

<p>When you setup an ingress (i.e.: nginx-ingress), a Service type <code>LoadBalancer</code> is created for the ingress-controller pods and a Load Balancer in you cloud provider is automatically created and a public IP will be assigned for the nginx-ingress service.</p>

<p>This load balancer/public ip will be used for incoming connection for all your services, and nginx-ingress will be the responsible to handle the incoming connections.</p>

<p>For example:</p>

<p>Supose you have 10 services of <code>LoadBalancer</code> type: This will result in 10 new publics ips created and you need to use the correspondent ip for the service you want to reach.</p>

<p>But if you use a ingress, only 1 IP will be created and the ingress will be the responsible to handle the incoming connection for the correct service based on PATH/URL you defined in the ingress configuration. With ingress you can:</p>

<ul>
<li>Use regex in <code>path</code> to define the service to redirect;</li>
<li>Use SSL/TLS </li>
<li>Inject custom headers;</li>
<li>Redirect requests for a default service if one of the service failed (default-backend);</li>
<li>Create whitelists based on IPs</li>
<li>Etc...</li>
</ul>

<p>A important <a href="https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#caveats-and-limitations-when-preserving-source-ips" rel="noreferrer">note</a> about Ingress Load balancing in ingress:</p>

<blockquote>
  <p>GCE/AWS load balancers do not provide weights for their target pools. This was not an issue with the old LB kube-proxy rules which would correctly balance across all endpoints.</p>
  
  <p>With the new functionality, the external traffic is not equally load balanced across pods, but rather equally balanced at the node level (because GCE/AWS and other external LB implementations do not have the ability for specifying the weight per node, they balance equally across all target nodes, disregarding the number of pods on each node).</p>
</blockquote>
