The application has multiple pipelines which build docker images on each. Multiple APIs and a react web application.
The current helm chart is set up to have multiple services and deployments and one ingress controller.
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.
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?
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.
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.
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:
metadata:
name: service1
spec:
rules:
- host: service1.domain.com
http:
paths:
- backend:
serviceName: service1
servicePort: 80
path: /and then for the second service:
metadata:
name: service2
spec:
rules:
- host: service2.domain.com
http:
paths:
- backend:
serviceName: service2
servicePort: 80
path: /and they would work together without colliding. If you are using path based routing, you'd have to make sure paths dont collide.
It is very common to have only one ingress controller (replicated) with many ingress rules. Even more, this is the purpose of ingress controller : only one "external endpoint" that routes requests on many "internal endpoints".
About helm structuration, it is generally better to have one chart per application, specially for version management. To have the best of the two options, you can add a kind of "meta chart" (also named umbrella chart), that will only contains a requirements.yaml file, that will list all the other charts. Using this kind of structure, it is easy to deploy only the specific chart you need for CI/CD, but you can also deploy your whole services with only one chart. Even more, you can release the "meta chart" after a full integration tests, to "certify" that all your applications versions are working together.
Helm official documentation is giving advises about this at https://helm.sh/docs/developing_charts/#complex-charts-with-many-dependencies.