I have a helm chart with an optional component. It seems that the preferred way to support optional components is to break them into separate charts and toggle them with tags.
I tried this, but my optional component needs to know a variable from the rest of the chart (the address of a particular service). This causes things to break
Error: render error in "subchart/foo-deployment.yaml":
template: superchart/templates/_helpers.tpl:14:40:
executing "superchart.variable <.Values.variable...>:
can't evaluate field name in type interface {}
I believe you can do this at install time for the chart
helm install --set option1=value1 --name my-release stable/dask
For more info:
https://docs.helm.sh/helm/#helm-install
Issue:
https://github.com/kubernetes/helm/issues/944
PR:
https://github.com/kubernetes/helm/pull/982
Related
Why write non-secret metadata as PLACEHOLDER in kubernetes yaml files? (from here):
namespace: PLACEHOLDER
Any reason to replace it with a later sed command? why not simply write it inside the yaml file?
Those values are normally replaced or overridden later, either by sed within a CI/CD pipeline like Jenkins, or (as indicated by the question you linked to) by Helm.
With helm, you can override values within the yamls either with a second yaml, or at the command line using --set switches.
So I could have
helm install nginx --values values.yaml --values values2.yaml
and the placeholder value in values.yaml would get overridden by the value in values2.yaml
Placeholders are often used to deliberately break an install is someone tries to install it without passing in the right values.yaml
For example:
helm install my-chart
Could break because of the placeholder value, but
helm install my-chart --values production.values.yaml
would install because the placeholder values are overridden and the chart can install correctly.
Based on my experience, when you see files like this, they might be used in some sort of pipelines to deploy them in multiple clusters. These files, from my prior experience, act like templates when you don't want to go all in with Helm charts for a single ConfigMap or Secret or a different isolated resource. This allows you to replace these placeholders with values corresponding with you cluster, region etc.
Hope this makes sense.
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