Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

274
Visualizações
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 Respostas
Responde à pergunta

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 Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda