Need advice on helm charts vs manifests based deployments

8k views Asked by At

In my current job we are running multiple k8s cluster and allowing multiple teams to run services in the cluster.

Each service/git repo will have kustomize file, which has list of all patches. During the CD phase, we are converting this kustomize to a k8s manifests (service,configmap,deployment) for a given env/region and running a kubectl apply commands to run in our kubernetes.

Now, we started looking at helm charts, instead of converting Kustomize to k8s manifests, plan is to generate the values.yaml file for the generic helm chart and deploy a helm release with git sha. so, Any thoughts or advices on this approach, is there any advantage of moving to helm chart release based deployments from k8s manifests. Also is there any advantages with helm chart when teams plan to do blue/green or canary deployments ?

The goal is to:

  1. Have an artifact
  2. Rollback plan
  3. Test cases to validate the yamls and to check if the services are up or not.

Any leads would be highly appreciated.

1

There are 1 answers

1
Ilia Kondrashov On

Helm can do multiple things for you:

  • template k8s manifests - similar to what Kustomize is currently doing in your setup
  • take care about upgrading installations - that includes removing deletes resources
  • keep track of revisions of your installations - so you can rollback easily
  • allow you to add helmcharts to your application as a dependency - so your application chart will also include mysql and redis for example - all managed in one place and deployed together
  • define chart for default microservice (with monitoring, ingress config etc) with extensive configuration options and use it across most of the teams in your company
  • etc

Looks like the last point matches your demand quite a lot, since you have many applications from multiple teams.

I think helm with reusable charts a great next step from raw k8s manifests.

Also you can define tests to be executed to validate the release.