I am currently trying to make changes to system where access to the helm chart is not given.
Basically I am trying to call:
helm upgrade my-already-working-software "chart-should-go-here-but-I-do-not-have-access" --reuse-values -f "$OVERRIDEFILE"
to override e.g. ressource settings.
Is there any way possible to extract the chart from e.g. the helm history or it's values?
Related
I have a helm chart containing Kubernetes job but unfortunately helm upgrade won't work because the image name is immutable so logically I need to do a delete and install but I will loose my set values.yaml if they were customised in the first place.
How can I keep the values before deleting the chart and use them for new install to simulate an upgrade? I couldn't find anything in documentations or here.
Thanks
EDIT:
First you need to get your previous values with helm get values <release-name>
So you could redirect the values to a file with:
helm get values <release-name> -o yaml > values.yaml
And then do a helm install again
I have helm charts created for a microservice that I have built and everything is working as expected. Now, I have created a new k8s namespace and I want to try to deploy the same helm charts as my old namespace. Although, I have just one value that I need it different while everything else remain the same.
Do I have to create another values.yaml for the new namespace and copy everything over and update the one field I want updated ? Or is there any other way ? I do not want to use the --set method of passing updates to the command line.
David suggested the right way. You can use different values.yaml where you can specify the namespace you want to deploy the chart:
$ helm install -f another-namespace-values.yaml <my-release> .
It's also entirely possible to launch helm chart with multiple values.
For more reading please check values section of helm docs.
Has anyone figured out any way to manipulate the chart (not values.yaml) when installing Helm charts?
For example, I have a bash script that basically does
helm3 upgrade --install <options>
Regardless of whatever the value of resources.limits.cpu is in any of my charts, I want to set it to a specific value when installing any charts. If all my charts were using {{ .Values.resources.limits.cpu }} I could use --set but my charts are inconsistent. Long term, proper solution is to have consistent charts, but I'm looking for a quick and dirty way.
I don't think you can change it with helm. But you could try using mutating webhook like the one here: https://github.com/garethr/kubernetes-webhook-examples/blob/master/src/app.py#L38-L41 to alter pods spec in flight as they are being created.
But if you are not using any helm specific features and use it only as templating engine, you can try the following quick and dirty hack:
helm template . | yq e '.spec.template.spec.containers[].resources.limits.cpu = "123"' /dev/stdin
Notice the use of helm template (to render templates) an yq (to change limit values)
I want to deploy nextcloud with helm and a custom value.yaml file that fits my needs. Do i have to specify all values given from the original value.yaml or is it possible to only change the values needed, Eg if the only thing I want to change is the host adress my file can look like this:
nextlcoud:
host: 192.168.178.10
instead of copying this file and changing only a few values.
As the underlying issue was resolved by the answer of user #Kun Li, I wanted to add some examples when customizing Helm charts as well as some additional reference.
As asked in the question:
Do i have to specify all values given from the original value.yaml or is it possible to only change the values needed
In short you don't need to specify all of the values. You can change only some of them (like the host from your question).
The ways to change the values are following:
Individual parameters passed with --set (such as helm install --set foo=bar ./mychart)
A values file if passed into helm install or helm upgrade with the -f flag (helm install -f myvals.yaml ./mychart)
If this is a subchart, the values.yaml file of a parent chart
The values.yaml file in the chart
You can read more about it by following official Helm documentation:
Helm.sh: Docs: Chart template guide: Values files
A side note!
Above points are set in the order of priority. The first one (--set) will have the highest priority to override the values.
Example
A side note!
This examples assume that you are in the directory of a pulled Helm chart and you are using Helm v3
Using the nextcloud Helm chart used in the question you can set the nextcloud.host value by:
Pulling the Helm chart and editing the values.yaml
Creating additional new-values.yaml to pass it in (the values.yaml from Helm chart will be used regardless with lower priority):
$ helm install NAME . -f new-values.yaml
new-values.yaml
nextcloud:
host: 192.168.0.2
Setting the value with helm install NAME . --set nextcloud.host=192.168.0.2
You can check if the changes were done correctly by either:
$ helm template . - as pointed by user #David Maze
$ helm install NAME . --dry-run --debug
you misspelled the nextcloud to nextlcoud in your value file.
I am new to the Kubernetes and especially using helm. I installed the charts and it works fine with default values. I want to the add smtp server setting in the values.yml file for the chart. I am confused on how to inject the values while installing the chart. This is the chart that I am using https://github.com/helm/charts/tree/master/stable/prometheus-operator.
After installing the helm chart with default values I see that there is a deployment called prometheus-operator-grafana which has values GF_SECURITY_ADMIN_USER and GF_SECURITY_ADMIN_PASSWORD but I am not sure where these values are coming from.
Help with how these values work and how to inject them would be appreciated.
The interaction between parent and child chart values is summarize very well in this SO answer: helm overriding Chart and Values yaml from a base template chart
There are two separate grafana chart mechanisms that control such a thing: adminUser and adminPassword or admin.existingSecret along with admin.userKey and admin.passwordkey
Thus, helm ... --set grafana.adminUser=ninja --set grafana.adminPassword=hunter2 will do what you want. The fine manual even says they are using grafana as a subchart, and documents that exact setting as the first value underneath the grafana.enabled setting. Feel free to file an issue with the helm chart to spend the extra characters and document the grafana.adminUser setting, too