<p>We are currently setting up a kubernetes cluster for deploying our production workloads (mainly http rest services).
In this cluster we have setup nginx ingress controller to route traffic to our services from the outside world. Since the ingress controller will be used mainly with path routing I do have the following questions:</p>

<ul>
<li><strong>Question 1: Dynamic backend routing</strong></li>
</ul>

<p>Is it possible to route the traffic to a backend, without specifically specifiying the backend name in the ingress specification? For example I have the followign ingress: </p>

<pre><code>apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: example-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - http:
      paths:
        - path: /apple
          backend:
            serviceName: apple-service
            servicePort: 8080
</code></pre>

<p>Is there any possibility that the /apple request is routed to the apple-service without specifically specifying it in the serviceName? So /apple is automatically routed to the apple-service service, /orange is automatically routed to the orange service without explicitly specifying the backend name?</p>

<ul>
<li><strong>Question Number 2</strong></li>
</ul>

<p>If there is no sulution to number 1 so that we can deploy based on some conventions, the question now goes further on how to manage the ingress in an automated way.
Since the services are going to be deployed by an automated CI/CD pipeline, and new paths may be added as services are added to cluster, how can the ci/cd orchestrator (e.g. jenkins) update the ingress routes when an application is deployed? So that we are sure, that no manual intervention is needed into the cluster and each route is deployed together with the respective service?</p>

<p>I hope that the information given is enough to understand the issue. 
Thank you very much for your support. </p>

<p>Just have a step in your ci/cd pipeline that checks for what the current ingress is and some kind of param if it needs to be updated. </p>

<p>High level steps...</p>

<pre><code>kubectl get ingress example-ingress -o yaml &gt; ex-ingress.yaml

</code></pre>

<p>you can write that output to a file and read it, updated it, verify it and so on. </p>

<p>and then push it to the cluster along with your deployment</p>

<pre><code>kubectl replace -f ex-ingress.yaml 
</code></pre>

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