I'm currently building an application that is composed of 4 microservices (a, b, c, d). We would like to make Kubernetes Helm part of our CI/CD pipeline.
We are at the point where we're discussing how best to define the charts and was wondering was the advice from the community.
Our current options appear to be:
- a chart per microservice (so 4 charts)
- a chart per "application flow" (service a calls b, service c calls d, so 2 charts in total)
- a single chart that deploys all 4 microservices
- some combination of 1. and 3. where we leverage the dependencies feature of Helm
It might be worth calling out that:
- we currently don't have a requirement to deploy any microservice in isolation e.g. make it available to a separate application.
- it is likely that we will need to have the ability to scale any microservice independently i.e. not simply replicate all 4 services.
I'm mentioning these requirements because I feel that they may be relevant to the chart design.
Might be a late answer, but FWIW, it depends on how and where you develop your microservices app. If each microservice has it's own repo and CI pipeline, then it makes sense to separate the charts as well (one per service). However, if all services are in the same repo and deployed with a single ci pipeline, then a single chart is a better fit.
All your 4 options will work. And whether you deploy your app with separate charts or with one won't make any difference as long as eventually all your services will be deployed.
As for scaling services independently, if you use separate deployments for your services in one big chart, you can scale them separately by using input values for each deployment in your values.yaml ... so it's not something which forces you to split your charts.
And for your image changing question in the comments, it only needs an upgrade for your installed release with the new image tag.
By the way, We use helmsman for deploying (and managing) helm charts from code in our CI/CD pipelines. Might be useful for you ;)
We have a similar problem, and we choose the lean way: first simple and functional, then evolve.
We started with a simple chart deploying all services because our main requirement it's to have one installer. But we know that in short time we are gonna to refactor to use 3rd party charts and even our own charts in our own repo to handle different deployment strategies and independent evolution of services.
Probably useful resource: https://medium.com/faun/dry-helm-charts-for-micro-services-db3a1d6ecb80
We’ll create a chart for each service, an Umbrella chart, and a Common chart.
The punch here is the Common chart. This chart will contain templates for all the common resources of our services, viz. Deployment, Service, Ingress, ConfigMap and more.
Each service chart will only include the common templates required for the service and supply service-specific values.
Finally, the Umbrella chart will (surprisingly) just unify the services charts.
