How to know what values are exposed/what is customizable in a helm chart?

Question

I may just be extremely slow, but I cannot wrap my head around this.

• There are repositories/hubs (artifacthub, etc.) with pointers to other repos that have helm charts
• I can add these charts as a 'dependency' in my helm Chart.yaml file, if I know the name/version/repository
• For example, for https://artifacthub.io/packages/helm/vultr/cert-manager-webhook-vultr the version=1.0.0, the dependency=vultr/cert-manager-webhook-vultr, and the repo=https://vultr.github.io/helm-charts (is this correct? Why are these 3 values not super visible. It always seems like a guessing game when trying to pull down charts)
• On artifacthub, there is a 'templates' section, which has various yaml files. Is this what properties are possible to modify on the chart? How do these helm template yamls that I define get applied to charts I have installed? (For example, if I have both nginx and traefik ingresses, will both of them get all the yamls for kind:Ingress applied to them?)
• Why does helm require me to pull down the cluster to my local repo to use it? Do people use helm to track releases in 'the real world'?
• In what scenario would I just do 'helm install X' as opposed to adding it to my Chart.yaml dependencies?

The helm docs (and lots of tutorials) are very terse and only show one off script examples. Shouldn't I want all of my 'infrastructure as code'? I don't understand the constant suggestions to 'helm add repo' and 'helm install' and then hand wave over any customization?

Answer 1

I think the interesting part of this question is the last bullet point, around what to helm install; the rest of it is details.

I can imagine four different "kinds" of Helm charts:

1. Library charts only contain {{- define -}} template blocks, but no Kubernetes resources. This is a first-class concept in Helm 3 but pretty rare in the wild.

2. "Infrastructure" charts contain a prepackaged piece of software, like PostgreSQL or Redis, that you're probably not directly using. They could depend on library charts.

3. "Application" charts contain, say, a single microservice, that you are directly using. They likely depend on infrastructure charts, for example to get a service-local database.

4. "Umbrella" charts depend on specific versions of several applications and describe the combined system.

So if you have a system, that consists of several services, and you want to track their releases, you have a couple of choices. One is to build an umbrella chart and helm upgrade that chart as new component builds arrive; this has the mechanical problem that Helm likes to combine dependencies, so the "service-local" database dependencies will all get combined into one. You can helm install the application charts individually, or use a tool like Helmfile or Helmsman to manage a set of adjacent installed charts.

Within that hierarchy, though, you generally would install "umbrella" or "application" charts, but not directly install "infrastructure" or library charts. Except in early experimentation you wouldn't typically helm install bitnami/redis, but instead include it as a dependency of your actual application.

---

You're basically correct on the mechanics of using dependency charts. Each chart includes a templates directory, and the templated YAML files there are installed in the cluster. Each chart also includes a values.yaml file at its top level, and that's the only way to configure a dependency chart. A parent chart can include configuration for its dependencies under a key with the dependency name

# application/values.yaml
#   Chart.yaml depends on a specific chart named "infrastructure"
infrastructure:
  # This would be a top-level key in values.yaml in
  # the "infrastructure" chart
  username: foo

You can't really modify the actual template content from dependency charts; you can only customize what gets produced by setting values. Some charts have better-documented values than others, and better ones have all of the details in their README.md file.

---

You ask about a couple of implementation choices, and it's hard to give concrete answers about those. You need to download dependencies into a local charts subdirectory (for example, with helm dep up), but I'm not sure why; I can imagine use cases around offline usage, where you transport a chart and its dependencies into an isolated network and run an installation there, but I can also imagine Helm preferring a charts directory and automatically downloading. Similarly, finding charts can in fact be tricky, but one part of this is that maintaining a package repository is both financially and operationally complex. There used to be an official "stable" charts repository but it was discontinued.

---

One last piece I'll bring up here is the notion of "cluster infrastructure". You can imagine wanting to run an ingress controller or a logging agent, for example, that might be packaged as a Helm chart. In my initial hierarchy I'd consider these as "applications"; a service chart could have a type: Ingress resource but wouldn't itself depend on the Nginx or Traefik ingress controllers. You could have a Helmfile setup for cluster infrastructure parallel to your core application setup, or manage them together if you're sure you're only running one copy of your system in a cluster.