<p>I have deployed a statefulset in AKS - My goal is to load balance traffic to my statefulset.</p>
<p>From my understanding I can define a LoadBalancer Service that can route traffic based on Selectors, something like this.</p>
<pre><code>apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  type: LoadBalancer
  ports:
  - port: 80
    name: web
  selector:
    app: nginx
</code></pre>
<p>However I don't want to necessarily go down the LoadBalance route and I would prefer Ingress doing this work for me,   My question is can any of the ingress controller support routing rules which can do Path based routing to  endpoints based on selectors? Instead of routing to another service.</p>
<p><strong>Update</strong>
To elaborate more on the scenario - Each pod in my statefulset is a stateless node doing data processing of a HTTP feed. I want my ingress service to be able to load balance traffic across these statefulset pods ( honoring keep-alives etc), however given the nature of statefulsets in k8s they are currently exposed through a headless service. I am not sure if a headless service can load balance traffic to my statefulsets?</p>
<p><strong>Update 2</strong>
Quick search reveals <a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer">headless</a> service does <em><strong>not</strong></em>  loadbalance</p>
<p><code>Sometimes you don't need load-balancing and a single Service IP. In this case, you can create what are termed &quot;headless&quot; Services, by explicitly specifying &quot;None&quot; for the cluster IP (.spec.clusterIP).</code></p>

<p>+1 to <a href="https://stackoverflow.com/users/5525824/harsh-manvar">Harsh Manvar's</a> answer but let me add also my 3 cents.</p>
<blockquote>
<p>My question is can any of the ingress controller support routing rules
which can do Path based routing to endpoints based on selectors?
Instead of routing to another service.</p>
</blockquote>
<p>To the best of my knowledge, the answer to your question is <strong>no, it can't</strong> as it doesn't even depend on a particular ingress controller implementation. Note that various ingress controllers, no matter how different they may be when it comes to implementation, must conform to the general specification of the <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" rel="nofollow noreferrer">ingress resource</a>, described in the official kubernetes documentation. You don't have different kinds of ingresses, depending on what controller is used.</p>
<p><a href="https://kubernetes.io/docs/concepts/services-networking/ingress/" rel="nofollow noreferrer"><code>Ingress</code></a> and <a href="https://kubernetes.io/docs/concepts/services-networking/service/" rel="nofollow noreferrer"><code>Service</code></a> work on a different layer of abstraction. While <code>Service</code> exposes a set of pods using a selector e.g.:</p>
<pre><code>apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp 👈
</code></pre>
<p>path-based routing performed by <code>Ingress</code> is always done between <code>Services</code>:</p>
<pre><code>apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test 👈
            port:
              number: 80
</code></pre>
