I'd like to check that my kubernetes helm chart does not define unused values in values.yaml. This should include any subcharts such that if you've defined subchart.foo.bar: ??? in the top-level values.yaml that key is definitely used in the subchart, or possibly as a short-cut mentioned in the subchart/values.yaml.
This is needed to prevent us from shipping bogus "documentation" in the values.yaml, for example if a key in a subchart has been changed or removed.
Ideally there would also be some possibility to report on which subchart values have not been overridden in the top-level chart, though this is less concerning.
Are there any existing tools that can help with this?
Since the Helm v3 release you can now define a schema for your values. On commands like helm install your provided values are automatically validated against the schema.
Please see the official documentation: https://helm.sh/docs/topics/charts/#schema-files
Schema validation works for subcharts too, this is also mentioned in the documentation on the link above.
AFAIK, there isn't a tool for that. However, it shouldn't be that hard to make one, even using bash. For example, you need to export all key/value pairs like this test.test1.test2 and grep for that string recursively in the templates folder. If you want to read yaml using bash, you can install shyaml. If you know how to code in Python, even better.
helm lint --detect-unused-values
Related
In a Kubernetes operator based on operator-sdk, do you know how to write code to synchronize CR resource when CR specification is updated with kubectl apply? Could you please provide some code samples?
It is mostly up to how you deploy things. The default skeleton gives you a Kustomize-based deployment structure so kustomize build config/default | kubectl apply -f. This is also wrapped up for you behind make deploy. There is also make install for just installing the generated CRD files.
Implementing it a go-lang based operator is pretty complex, and I would recommand studying the kubebuilder documentation and example in order to achieve that: https://book.kubebuilder.io/cronjob-tutorial/controller-implementation.html#implementing-a-controller
I deployed the kube-prometheus-stack helm chart. While this chart offers a really nice starting point it has lots of default dashboards which I do not want to use. In the values.yaml of the chart, there is an option defaultDashboardsEnabled: true, which seems to be what I am looking for but if I set it to false using the code below in my values file, which I mount into the helm chart, the dashboards are still there. Does anyone know why this does not work?
A possibility which I thought of is that the chart has both a subchart called grafana and an option grafana, but I do not know how I could fix it or test if this is the issue.
grafana:
defaultDashboardsEnabled: false
I`m placing this answer to better visibility as community might interested in other solutions.
First way would be setting grafana.enable: to false in values.yaml.
## Using default values from https://github.com/grafana/helm-charts/blob/main/charts/grafana/values.yaml
grafana:
enabled: true
With this your chart will not install grafana.
Another way would be to helm pull the chart to your local directory and then just delete the template.grafana directory (to launch the chart locally you just need to helm install <name> ./prometheus-stack)
I solved the issue by removing the namespace where Grafana was located. Apparently, there has been some resource left which was not removed by uninstalling the helm chart.
Edit:
The problem seems to be with the configmaps. It appears that in some of these the old configuration is saved even though it has already been changed in the helm chart. Removing the Grafana deployment and all the config maps in the regarding namespace worked for me.
Surely it is not necessary to remove all configmaps but I did not have the time to find out which one is the problem.
I have a query related with prometheus-operator helm chart & alert manager combination.
Currently we are using prometheus-operator helm chart:
https://github.com/helm/charts/tree/master/stable/prometheus-operator
and I wrote a simple rule in values.yml (this is just a sample code) to generate an alert:
further I am using alertmanager config/routes/receivers to send alerts. It's working perfectly fine.
But as part of real-time implementation, I may be having so many alert rules. Is there any way where I can bring these all rules in separate rules file & configure the path (rule file path) in values.yml (under: additionalPrometheusRules section)
I also saw kube-prometheus-stack & additionalPrometheusRulesMap (in values.yml):
https://github.com/prometheus-community/helm-charts/blob/main/charts/kube-prometheus-stack/values.yaml
But didn't fine any solution. Anyone can help me on this?
So helm doesn't allow includes in values.yaml files typically. I read that there's a way to do it, but it depends on how the chart is built and typically upstream maintainers don't use templates that way afaik (could be wrong there, but I've never noticed it).
Your problem is exactly the same problem I've been trying to solve adequately, and I think I came up with something. It's not perfect, but it is better than having one huge monolithic values.yaml file.
helm allows the operator to specify multiple values.yaml files using the paradigm, -f values1.yaml -f values2.yaml -f some-more-values.yaml, so I broke my values file up into multiple logically-divided yaml files.
There might be gotchas, so be aware, but so far for this use-case, it seems to be working. I'm still testing things out. https://helm.sh/docs/helm/helm_install/
You can also add your own custom rules file using config maps. In this way, you can avoid over alerting and get notified for specific alerts only.
I am using helm built in object 'Release.isUpgrade' to ensure an init-container is only run at upgrade.
I want to only run the init-container when upgrading from a specific Chart version.
Is it possible to get the 'from' Chart version in a helm upgrade ?
It doesn't look like this information is published either in the .Release object or through information available to a hook job.
You probably want a pre-upgrade hook and not an init container. If you have multiple replicas on your deployments, the init container will run on all of them; even if you have just one, if the node it's on fails and is replaced, the replacement will re-run the init container. A pre-upgrade hook will run just once, regardless of how the corresponding deployments are configured.
That hook will be a separate pod (and will require writing code), so within that you can do whatever you want. You can give it read access to the Kubernetes API to get the definition of an existing deployment, for example, and then look at its labels or container image tag to find out what version of the chart/application is running now. (There are standard labels that can help with this.) You could also make the upgrade step just look for its own outputs: if object X is supposed to exist, create it if it's not there, without focusing on specific versions.
I have just started experimenting with Helm kubernetes package manager.
But chart vs template topic seems a bit confusing to me.
I understand that by template I will create kubernetes yaml, which will create the objects and install them.
However the same is true for charts as well, but this latter is an abstraction over the yamls. And ./Charts containns standalone charts, while ./templates is valid only for the base chart. So I know that. But when should I include an other chart or just create a template?
Looking for different kind of charts through the web I still don't know which to use.
Say I have a project called MyApp, which has one component named MyServer which will communicate to MySql.
So I created a chart and put in it MyServer as a template :
./MyApp/templates/MyServer.yaml
What should I do with MySql?
I have seen both solutions in different projects, one just creates an other template:
./MyApp/templates/MySQL.yaml
on other project I saw a chart for MySql from a chart repository:
./MyApp/charts/mysql-version.tgz
On the top of that I have seen a bigdata project (hdfs,kafka,zookeeper,ELK,oracle db..etc) and one component was included as chart in ./charts other was created as a template in./templates.
This whole decision between chart and template seems random and confusing to me.
Could you explain it please when to use which?
A chart is a collection of templates, plus a little extra information like the metadata in the Chart.yaml file and the default values.yaml. In your example, MyApp is itself a chart.
For well-known dependencies (particularly things in the Helm charts repository and especially the stable charts) you're probably better off using the external chart; declare the dependency in your requirements.yaml or (Helm v3) Chart.yaml file and run helm dependency update. This lets you import the chart with two lines, rather than reproducing the StatefulSet, PersistentVolumeClaim, etc. that are included in the chart.