Kubernetes ingress update with deployment

Question

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:

• Question 1: Dynamic backend routing

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:

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

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?

• Question Number 2

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 (eg 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?

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

Answer 1

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.

High level steps...

kubectl get ingress example-ingress -o yaml > ex-ingress.yaml

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

and then push it to the cluster along with your deployment

kubectl replace -f ex-ingress.yaml 

https://kubernetes.io/docs/concepts/services-networking/ingress/

Answer 2

Question 1: Dynamic backend routing

Each Ingress Rule shall contain a list of paths each of which has an associated backend defined with a serviceName and servicePort . A backend is a combination of Service and port names as described in the Service doc .

An Ingress with no rules sends all traffic to a single default backend. The default backend is typically a configuration option of the Ingress controllerand is not specified in your Ingress resources.

If none of the hosts or paths match the HTTP request in the Ingress objects, the traffic is routed to your default backend.

There are a lot of additional Ingress controllers . My be some of these support such a feature.

Question Number 2

I agree with David Walton. Having additional step in CI/CD pipeline might be the best option here.

Answer 3

第 2 点的解决方案最终是每个服务部署都可以与每个自己的入口一起部署，因此不需要第 1 点。也就是说，您可以部署多个入口规则。

Answer 4

My solution is to have separate helm chart for ingress deployment per each environment (k8s namespace). In values I have a list of my apps, and it can be redefined during apply/update the helm chart deployment. Helm chart template has a loop to add rules for each element in the list.

On the jenkins job i run the kubectl to get the list of current services in the namespace, and put this list like an input variable for this helm chart. After each application deployment this “alb-update-rules” job is triggered. In case I deploy whole env with multiple services, I just trigger this job in the very end.

It works pretty good and might be enough in this case.