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
Related
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.
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.
How can I execute "helm install" command and re-install resources that I have defined in "templates"? I have some custom resources that already exist so I want to re-install them. It is possible to do that through a parameter in helm command?
I think your main question is:
I have some custom resources that already exist so I want to re-install them.
Which means DELETE then CREATE again.
Short answer
No.. but it can be done thru workaround
Detailed answer
Helm manages the RELEASE of the Kubernetes manifests by either:
creating helm install
updating helm upgrade
deleting helm delete
However, you can recreate resources following one of these approaches :
1. Twice Consecutive Upgrade
If your chart is designed to enable/disable installation of resources with Values ( .e.g: .Values.customResources.enabled) you can do the following:
helm -n namespace upgrade <helm-release> <chart> --set customResources.enabled=false
# Then another Run
helm -n namespace upgrade <helm-release> <chart> --set customResources.enabled=true
So, if you are the builder of the chart, your task is to make the design functional.
2. Using helmfile hooks
Helmfile is Helm of Helm.
It manage your helm releases within a single file called helmfile.yaml.
Not only that, but it also can call some LOCAL commands before/or/after installing/or/upgrading a Helm release.
This call which happen before or after, is named hook.
For your case, you will need presync hook.
If we organize your helm release as a Helmfile definition , it should be :
releases:
- name: <helm-release>
chart: <chart>
namespace: <namespace>
hooks:
- events: ["presync"]
showlogs: true
command: kubectl
args: [ "-n", "{{`{{ .Release.Namespace }}`}}", "delete", "crd", "my-custom-resources" ]
Now you just need to run helmfile apply
I know that CRD are not namespaced, but I put namespace in the hook just to demonstrate that Helmfile can give you the namespace of release as variable and no need to repeat your self.
You can use helm upgrade to upgrade any existing deployed chart with changes.
The upgrade arguments must be a release and chart. The chart argument can be either: a chart reference(example/mariadb), a path to a chart directory, a packaged chart, or a fully qualified URL. For chart references, the latest version will be specified unless the --version flag is set.
To override values in a chart, use either the --values flag and pass in a file or use the --set flag and pass configuration from the command line, to force string values, use --set-string. In case a value is large and therefore you want not to use neither --values nor --set, use --set-file to read the single large value from file.
You can specify the --values'/'-f flag multiple times. The priority will be given to the last (right-most) file specified. For example, if both myvalues.yaml and override.yaml contained a key called 'Test', the value set in override.yaml would take precedence
For example
helm upgrade -f myvalues.yaml -f override.yaml redis ./redis
easier way I follow, especially for pre existing jobs during helm upgrade is do kubectl delete job db-migrate-job --ignore-not-found
how to persist the parameter key values to values.yaml file while use command line to set the values.helm install . --name test --set image.tag=2020 --set image.version=20 how to update this image.tag and image.version values to values.yaml? dry run will give the result but wont update the values.yaml
Helm is a package manager, and it's all about automating deployment of kubernetes apps. It's designed to be somewhat static, and only being changed by the creator of the chart.
Values Files provides access to values passed into the chart. Its contents come from multiple sources:
The values.yaml file in the chart
If this is a subchart, the values.yaml file of a parent chart
A values file if passed into helm install or helm upgrade with the -f flag (helm install -f myvals.yaml ./mychart)
Individual parameters passed with --set (such as helm install --set foo=bar ./mychart)
This is the base Hierarchy of the values files, but there is more to it:
Kudos to the creator of this image, unfortunately I wasn't able to find the author to credit him.
You can't change the chart values.yaml file exacly as you are thinking, because the original values.yaml will keep the state desired by the creator of the chart.
The flowchart above is all about changes made during helm install or helm upgrade.
I'll try to exemplify your use scenario:
Chart 1 has the default values with:
image: original-image
version: original-version
You decided to deploy this chart changing some values using --set as in your example helm install --name abc --set image=abc --set version-123. Resulting in:
image: abc
version: 123
Then you want to upgrade the chart and modify the version value but keeping the other values as set, you run: `helm upgrade --set version=124 --reuse-values, here is the result values in effect:
image: abc
version: 124
NOTE: As we seen in the flowchart, if you don't specify --reuse-values it will reset the values that were not --set during the upgrade to back to the original of the chart. In this case image would again be original-image.
So, to wrap up your main question:
how to persist --set key values to values.yaml in helm install/upgrade?
You can persist the --set values during the upgrade by always using --reuse-values, however the changes will never be commited to the original template of values.yaml file.
If you are the owner of the chart, It's the recommended behavior that you create release versions of your chart, so you can keep track of what were the default in each version.
I hope it helps clarifying the issue.
If I can help you any further, let me know in the comments.
You can cpy the stuff from kubes when the depl/change is ready with kubectl get -o yaml
it is not quite the same of course.
When I use helm install to install a chart into a Kubernetes cluster, I can pass custom values to the command to configure the release. helm must store them somewhere, because I can later rollback to them. However, I cannot find a way to view the values in the deployed version or the previous one.
I want to see what values will change (and confirm what values are set) when I rollback a release. I thought inspect or status might help with that, but they do different things. How can I see the values that were actually deployed?
To view what was actually deployed in a release, use helm get.
If you use helm -n <namespace> get all <release-name> you get all the information for the current release of <release-name> in namespace <namespace>†. You can specify --revision to get the information for a specific version, which you can use to see what the effect of rollback will be.
You can use helm -n <namespace> get values <release-name> to just get the values install used/computed rather than the whole chart and everything, or helm -n <namespace> get manifest <release-name> to view the generated resource configurations††.
Where this information is stored depends on the version of helm you are using:
For version 3, it is (by default) in a secret named <release-name>.<version> in the namespace where the release was deployed. The content of the secret is about the same as what was in the helm version 2 configMap
For version 2: it is in a configMap named <release-name>.<version>, in the kube-system namespace. You can get more detail on that here.
†For helm version 2, use helm get <release-name> instead of helm get all <release-name>
††For helm version 2, release names had to be unique cluster-wide. For helm version 3, release names are scoped to namespaces, and the helm command operates on the "current" namespace unless you specify a namespace using the -n or --namespace command line option.
helm get <release-name> no longer works with Helm3. helm get values <release-name> does show the custom values used for the release. Note: to get all possible values for reference, use helm show values <your-chart> - this doesn't show the custom values though.