Is there a way to combine helm with some other tool for k8s configuration management without conflicts?

Question

Currently I have a k8s project with multiple services which are managed by a helm chart. Said helm chart is installed on my local machine and I want to keep it this way if it's possible. But now I need to provide a simple user-friendly way to change versions of some service's docker images for other people. I was thinking about creating a jenkins task which would allow changing "image" field for those services, but it would create conflicts with my helm release: next time I update something with helm, it would rollback jenkins "image" field changes to the values in my helm chart.

Is there a simple way to resolve this conflict, like saying helm not to change "image" field? If not, how can I continue using helm for project configuration while allowing "image" field changes from jenkins?

Answer 1

Helm isn't made to be used this way. If you'd prefer to use a static deployment, you're better off using a plain Kubernetes manifest. Then, people changing the image field won't break your release.

You can easily convert it to one simply by running helm get manifest command

Helm is used to manage release versions. I.e. every new release (and a docker image change definitely qualifies as one), you would push a change to your helm chart.

The other alternative you have is defining docker image as a value. Then you can pass a command-line argument to replace the image tag with a new one and re-run helm from Jenkins any time you have a new deploy.

Example:

in values.yaml:

image: 
  repo: foo
  tag: bar

On command line when running helm:

helm upgrade --install my-app --set image.tag=newtag

Final, and least recommended way is to use a mutable tag (i.e. "master") and set your ImagePullPolicy to Always. This way, when you have a deploy, you just need to bounce all the pods in your deployment/daemonset/statefulset object.