Question

0

139

Views

Kubernetes deployment style for multiple Ingresses on the same hostname. Are split configurations and single configuration equivalent?

I have two applications: app1 and app2. Each hosted in a separate repository. Each are completely unrelated from one another. I would like to:

Serve them from the same hostname, just at different paths.
Each application is independent from the other, and so are their deployment scripts.

My current approach is to have one yaml file per each application, describing Deployment, Service, and Ingress. I am using nginx to manage the ingress part.

app1.yaml contains the following Ingress specification:

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
    name: app1-ingress
    annotations:
        kubernetes.io/ingress.class: nginx
        nginx.ingress.kubernetes.io/proxy-read-timeout: "1800"
        nginx.ingress.kubernetes.io/proxy-send-timeout: "1800"
        nginx.ingress.kubernetes.io/rewrite-target: /$2
        nginx.ingress.kubernetes.io/configuration-snippet: |
            rewrite ^(/apps/app1)$ $1/ redirect; # ZZZ
spec:
    rules:
    - host: myhost
      http:
        paths:
        - path: /apps/app1(/?)(.*)
          backend:
            serviceName: app1-service
            servicePort: 8080

app2.yaml contains the exact equivalent, with the appropriate entries changed. When I want to deploy app1, I go into its repo and do:

kubectl apply -f app1.yaml

When I want to deploy app2, I go into its repo and do:

kubectl apply -f app2.yaml

The alternative is to have app1.yaml and app2.yaml just define the service, and then have an additional file containing the Ingress specification:

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
    name: ingress
    annotations:
        kubernetes.io/ingress.class: nginx
        nginx.ingress.kubernetes.io/proxy-read-timeout: "1800"
        nginx.ingress.kubernetes.io/proxy-send-timeout: "1800"
        nginx.ingress.kubernetes.io/rewrite-target: /$2
        nginx.ingress.kubernetes.io/configuration-snippet: |
            rewrite ^(/apps/.*)$ $1/ redirect; # ZZZ
spec:
    rules:
    - host: myhost
      http:
        paths:
        - path: /apps/app1(/?)(.*)
          backend:
            serviceName: app1-service
            servicePort: 8080
        paths:
        - path: /apps/app2(/?)(.*)
          backend:
            serviceName: app2-service
            servicePort: 8080

Assume that I am going to add more and more applications app3, app4 and so on in the future.

My question is: are these two specification styles equivalent, or is it one style preferred for technical or best practices reasons?

8 months ago · Santiago Trujillo

1 answers

Answer question

0

Answer question

Find remote jobs

Answer 1 · 2022-06-01T12:57:44.979Z

Your question is quite opinion based and it is impossible to give an unequivocal answer.

From my experience, it's better to use ingress per one service. For longer period of time it's comfortable - imagine one day you need to add / change some annotations in ingresss related to one specific service or group of services - you will need to divide your ingress into few files. It will create a mess. That's why it's better to keep ingress definitions separated - especially you have apps hosted in different repositories.

Also check this question (It's about hosts, not the paths, but it very similar to your question). You may find here many useful information.