Helm Configuration

From NovaOrdis Knowledge Base
Revision as of 23:49, 24 September 2019 by Ovidiu (talk | contribs) (Created page with "=Internal= * Helm Concepts =Overview= chart installation or upgrade process consists in using the chart artifacts, which may opti...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Internal

Overview

chart installation or upgrade process consists in using the chart artifacts, which may optionally contain a hierarchy of dependencies, and applying specific configuration with the end goal of producing a release. This section describes where the default chart's configuration lives, how external configuration values can be provided to the installation process, how configuration is processed during installation and how the effective configuration values surface in the release.

Runtime Configuration Tree

A useful mental image we will often refer to in this section is that the helm installation runtime builds a unique runtime configuration tree that serves as authoritative source of truth for the release configuration. Various templates use it to pull effective configuration values to be rendered in the manifests. The initial structure of the tree is based on the content of the chart's values.yaml configuration file.

The content of the runtime configuration tree is displayed at installation time in the "COMPUTED VALUES" section, if the --debug flag is used with helm install. For the following values.yaml content:

color: 'blue'
details:
  shape: 'square'
  components:
    - wheel
    - trunk

"helm install --debug ..." produces the following output:

...
COMPUTED VALUES:
color: blue
details:
  components:
  - wheel
  - trunk
  shape: square

which corresponds to the following runtime configuration tree:

 .
 |
 +- color: blue
 |
 +- details
       |
       +- shape: square
       +- components: [wheel, trunk]

Runtime Configuration Tree in Presence of Dependencies

If a chart has one or more dependencies, each dependency (subchart) contributes a subtree to the runtime configuration tree. Each dependency subtree is installed in the root of the runtime configuration tree under a label equal with the subchart name. Assuming that the above configuration belongs to a chart "a", which has a dependency "b", which in turn has a values.yaml with the following content:

color: 'red'

then the effective runtime configuration tree at installation is:

 .
 |
 +- color: blue
 |
 +- details
 |     |
 |     +- shape: square
 |     +- components: [wheel, trunk]
 +-b
   |
   +-color: red
   +-global: {}

If the second dependency, "c" is added to chart "a", and its values.yaml contains:

color: 'green'

the effective runtime configuration tree at installation is:

 .
 |
 +- color: blue
 |
 +- details
 |     |
 |     +- shape: square
 |     +- components: [wheel, trunk]
 +-b
 | |
 | +-color: red
 | +-global: {}
 +-c
   |
   +-color: green
   +-global: {}

Default Configuration

A chart comes with default configuration specified in the values.yaml file. The content of this file is used to build the initial instance of the runtime configuration tree. The content of the values.yaml file can rendered, verbatim, with:

helm inspect values <chart>

Unless overridden as described blow, these values can be accessed by templates via the Values object.

Overriding Default Configuration

The default values.yaml values can be overridden, in order, by:

  • If this is a subchart, by the corresponding values present in the values.yaml file of the parent chart.

If two or more of configuration sources listed above are used at the same time, the lowest in the list has priority.

Charts may, and usually will, expose configuration options. To see what configuration options are available for a chart use helm inspect values. Any available configuration option can be overridden by providing a YAML-formatted file during installation with the helm install -f|--values flag, or individually, on a configuration option basis, with --set.


  • A value file supplied with helm install -f (or helm upgrade -f)
  • The value passed with --set or --set-string on helm install or upgrade
  • The content of a file passed with --set-file on helm install or upgrade

The effective value specified by one or more of these sources can be accessed from templates with:

 {{ .Values.fieldName }}

A value specified values.yaml can be effectively effectively eliminated, by setting that value to null with

... --set <key>=null

Accessing Configuration from Templates

The 'Values' Object

Reconcile this and Helm_Templates#Values.

The 'Values' Object offers access to the runtime configuration tree, containing the effective configuration values which result after overriding default value with installation-time values.








Helm_Chart_values.yaml

Overriding Default Configuration TO DEPLETE

Overriding configuration can be provided:

The actual configuration hierarchy can be rendered during the release with --debug.

Each piece of configuration can be referred to from templates with .Values

Effective Values

All user-supplied values and computed values can be inspected at installation time if the --debug flag is provided to helm install:

helm install --debug ...
USER-SUPPLIED VALUES:
{}

COMPUTED VALUES:
color: blue
subject: have a nice day


Exporting Configuration Elements

requirements.yaml import-values

TODO: https://helm.sh/docs/developing_charts/#using-the-child-parent-format, https://github.com/ovidiuf/playground/blob/master/helm/export/README.md

TODO

TODO

  • ‘(.) --set for dependent charts. We need to provide the name of dependent chart up top. Understand why we need c3-selenium.selenium….