I have a umbrella chart and I want to know if it's possible to update an existing helm deployment through my requirements.yaml in my umbrella chart.
Not directly. If you did some kind of funky CRD with one of the existing Helm operators then maybe, but overall releases don't know about each other.
Related
For a regular helm-chart I can use helm package --app-version="foo-bar" to be able to overwrite app-version while packing the helm chart.
Is there a way to achieve the same with sub-charts.
Consider the following helm-chart structure
uber-chart
\sub-chart-1
\sub-chart-2
\sub-chart-3
Is it possible to pass different app-versions to different sub-charts while packaging uber-chart?
We have several resources deployed as part of a helm (v3) chart. Some time ago, I made changes to resources deployed by that helm chart manually, via kubectl. This caused some drift between the values in the yaml resources deployed by the helm release (as show by helm get values <release>) and what is actually deployed in the cluster
Example: kubectl describe deployment <deployment> shows an updated image that was manually applied via a kubectl re-apply. Whereas helm show values <release> shows the original image used by helm for said deployment.
I realize that I should have performed a helm upgrade with a modified values.yaml file to execute the image change, but I am wondering if there is a way for me to sync the state of the values I manually updated with the values in the helm release. The goal is to create a new default values.yaml that reflect the current state of the cluster resources.
Thanks!
This is a community wiki answer posted for better visibility. Feel free to expand it.
According to the Helm issue 2730 this feature will not be added in the Helm, as it is outside of the scope of the project.
It looks like there is no existing tool right from the Helm, that would help to port/adapt the life kubernetes resource back into existing or new helm charts/releases.
Based on this, you can use one of the following options:
As suggested by #David Maze. The Helm Diff Plugin will show you the difference between the chart output and the cluster, but then you need to manually update values.yaml and templates.
The helm-adopt plugin is a helm plugin to adopt existing k8s resources into a new generated helm chart.
I have an umbrella chart containing multiple subcharts. I want to ensure that the subcharts are installed in a given order since some of them have dependencies on the others. Specifying them as hook resources can only control the order within the sub chart. Is there a way to control the order in such a way that the subcharts get installed in the specified order?
Helm itself does not provide any tolling to control the installation order of the dependency charts. However, you can use any helm controller or CI/CD tool like Flux to manage such dependency order.
Here, is an example of managing order of charts using Flux CD: https://fluxcd.io/docs/components/helm/helmreleases/#helmrelease-dependencies
I have question regarding the Helm Chart. I'm curious whether this scenario can be implemented. I have Helm Chart #1 which holds deployment resource. The Helm Chart #2 should copy the manifest file (like a template) from Helm Chart #1, and modify some values (such as label) dynamically.
Can this be achieved?
You can create Helm Template and override the values using -f values.yaml!
Is there a way to create own boilerplate helm chart and then generate from it helm charts for my micro services (which will differ only in chart names)?
Yes, you'd need to create a package of your base boilerplate chart and then reference it in the requirements.yaml for other charts which depend on it.
Ref: https://helm.sh/docs/developing_charts/#chart-dependencies
Use helm create command to create boiler template, then changes are up to yourself.
$ helm create mychart
Ref: https://helm.sh/docs/helm/#helm-create