<p>When I went through thsis <a href="https://github.com/Kong/kubernetes-ingress-controller/blob/master/deploy/minikube.md" rel="nofollow noreferrer">doc</a> for implementing KONG Ingress Controller for Kubernetes, It was mentioned </p>

<blockquote>
  <p>One of the main features provided by an Ingress controller is the
  ability to react to changes in the Kubernetes cluster. This means if
  we scale a deployment or a pod dies we need to update the Kong
  configuration (a Target in this case)</p>
</blockquote>

<p>They say that they regularly check for changes in a POD and update the KONG UPSTREAM's TARGET accordingly. My Question is, this is what a Service in Kubernetes is designed for, Why not point directly to the Service <strong>ClusterIP</strong> and <strong>Port</strong> itself which will act as Internal Service Discovery.</p>

Arun Veeramani
<p>Excerpt from Kong ingress controller <a href="https://github.com/Kong/kubernetes-ingress-controller" rel="nofollow noreferrer">readme</a>: </p>

<blockquote>
  <p>Why endpoints and not services</p>
  
  <p>The Kong ingress controller does not use Services to route traffic to
  the pods. Instead it uses the Endpoints API to bypass kube-proxy to
  allow Kong features like session affinity and custom load balancing
  algorithms. It also removes overhead, such as conntrack entries for
  iptables DNAT.</p>
</blockquote>
