<p>after deploying nginx ingress controller there are two services in the nginx namespace</p>
<pre><code>NAME                                 TYPE           CLUSTER-IP    EXTERNAL-IP      
ingress-nginx-controller             LoadBalancer   10.28.13.78    
ingress-nginx-controller-admission   ClusterIP      10.28.8.39    
</code></pre>
<p>I understand the external ip maps to the external load balancer that routes traffic to ingress,  but what is the functionality of this ClusterIP ?
Does this clusterIP routes traffic to application services, and then application pods?</p>

user2600411
<blockquote>
<p>I understand the external ip maps to the external load balancer that
routes traffic to ingress, but what is the functionality of this
ClusterIP ?</p>
</blockquote>
<p><code>ClusterIP</code> type service abstraction is also doing a load balancing but cluster internal. It's not some running instance as a load balancer you already know. <code>kube-proxy</code> configures <code>ip-tables</code> rules for each pod fronted by this <code>ClusterIP</code> service and randomly routes traffic to different pods (as the same TCP session packets will directed to the same pod otherwise pods will end up not being able to decode meaningful data).</p>
<blockquote>
<p>Does this clusterIP routes traffic to application
services, and then application pods?</p>
</blockquote>
<p>No, That's not right. To send traffic from Ingress to application pods it uses a <code>ClusterIP</code> of the application service. Here you also get a <code>ClusterIP</code> when creating a <code>LoadBalancer</code> type service by default. It is for convenience to not use external IP for internal service to Ingress communication that you may want.</p>
<p>For example: If you want to call a service fronted by ingress but from a pod in the same cluster, then you can use <code>ClusterIP</code> and avoid <em>traffic hair-pinning</em> (traffic initiated from the cluster leaving the cluster and re-entering the cluster again).</p>
