Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

273
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:

  1. Serve them from the same hostname, just at different paths.
  2. 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?

over 4 years ago · Santiago Trujillo
1 answers
Answer question

0

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.

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!