<p>The application has multiple pipelines which build docker images on each. Multiple APIs and a react web application.</p>

<p>The current helm chart is set up to have multiple services and deployments and one ingress controller.</p>

<p>Doing it this way means that the whole product is in a single helm chart, which is good. However, it means that when it comes to CI/CD, if the tag changes for one of the APIs, we need to figure out which tag to use for the other images.</p>

<p>I've thought about creating a Helm chart for each application but then how would the ingress controller work? Would you have an ingress controller for each chart and let Kubernetes figure out which one to use based on the regex rules?</p>

<p>There has to be better structure for this sort of thing and I'm stuck. I've heard the term "Umbrella chart" but not really too sure what that means. </p>

James B.
<p>This really depends on how you would want it to be, you can create a single chart for everything or you can create a chart per application.</p>

<p>If you create a chart per application you just create a single ingress for each application and it merges them into a single ingress definition (kinda). this is how it looks for me:</p>

<pre><code>metadata:
  name: service1
spec:
  rules:
  - host: service1.domain.com
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80
        path: /
</code></pre>

<p>and then for the second service:</p>

<pre><code>metadata:
  name: service2
spec:
  rules:
  - host: service2.domain.com
    http:
      paths:
      - backend:
          serviceName: service2
          servicePort: 80
        path: /
</code></pre>

<p>and they would work together without colliding. If you are using path based routing, you'd have to make sure paths dont collide.</p>
