Designing Helm charts for microservices based application

22
votes

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:

  1. a chart per microservice (so 4 charts)
  2. a chart per "application flow" (service a calls b, service c calls d, so 2 charts in total)
  3. a single chart that deploys all 4 microservices
  4. 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.

3
kubernetes-helm
I'm also struggling with this question. We have hundreds of micro-services, so, for now, the plan is chart per type: web API, a worker that read from queue etc. We're still in the process of trying it, but chart per API seems like too much overhead - most of the template is common and can be reused. BTW if you want to test your chart take a look here: github.com/omerlh/helm-chart-tests-demo – Omer Levi Hevroni

3 Answers

5
votes

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 ;)

2
votes

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.

-1
votes

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.