- Glossary
- Chart
- Chart Archive
- Chart Dependency (Subcharts)
- Chart Version
- Chart.yaml
- Helm (and helm)
- Helm Configuration Files (XDG)
- Kube Config (KUBECONFIG)
- Lint (Linting)
- Provenance (Provenance file)
- Release
- Release Number (Release Version)
- Rollback
- Helm Library (or SDK)
- Repository (Repo, Chart Repository)
- Values (Values Files, values.yaml)
Glossary
Chart
A Helm package that contains information sufficient for installing a set ofKubernetes resources into a Kubernetes cluster.
Charts contain a Chart.yaml
file as well as templates, default values(values.yaml
), and dependencies.
Charts are developed in a well-defined directory structure, and then packagedinto an archive format called a chart archive.
Chart Archive
A chart archive is a tarred and gzipped (and optionally signed) chart.
Chart Dependency (Subcharts)
Charts may depend upon other charts. There are two ways a dependency may occur:
- Soft dependency: A chart may simply not function without another chart beinginstalled in a cluster. Helm does not provide tooling for this case. In thiscase, dependencies may be managed separately.
- Hard dependency: A chart may contain (inside of its
charts/
directory)another chart upon which it depends. In this case, installing the chart willinstall all of its dependencies. In this case, a chart and its dependenciesare managed as a collection. When a chart is packaged (viahelm package
) all of its hard dependencies arebundled with it.
Chart Version
Charts are versioned according to the SemVer 2 spec. Aversion number is required on every chart.
Chart.yaml
Information about a chart is stored in a special file called Chart.yaml
. Everychart must have this file.
Helm (and helm)
Helm is the package manager for Kubernetes. As an operating system packagemanager makes it easy to install tools on an OS, Helm makes it easy to installapplications and resources into Kubernetes clusters.
While Helm is the name of the project, the command line client is also namedhelm
. By convention, when speaking of the project, Helm is capitalized. Whenspeaking of the client, helm is in lowercase.
Helm Configuration Files (XDG)
Helm stores its configuration files in XDG directories. These directories arecreated the first time helm
is run.
Kube Config (KUBECONFIG)
The Helm client learns about Kubernetes clusters by using files in the Kubeconfig file format. By default, Helm attempts to find this file in the placewhere kubectl
creates it ($HOME/.kube/config
).
Lint (Linting)
To lint a chart is to validate that it follows the conventions andrequirements of the Helm chart standard. Helm provides tools to do this, notablythe helm lint
command.
Provenance (Provenance file)
Helm charts may be accompanied by a provenance file which provides informationabout where the chart came from and what it contains.
Provenance files are one part of the Helm security story. A provenance containsa cryptographic hash of the chart archive file, the Chart.yaml data, and asignature block (an OpenPGP “clearsign” block). When coupled with a keychain,this provides chart users with the ability to:
- Validate that a chart was signed by a trusted party
- Validate that the chart file has not been tampered with
- Validate the contents of a chart metadata (
Chart.yaml
) - Quickly match a chart to its provenance data
Provenance files have the .prov
extension, and can be served from a chartrepository server or any other HTTP server.
Release
When a chart is installed, the Helm library creates a release to track thatinstallation.
A single chart may be installed many times into the same cluster, and createmany different releases. For example, one can install three PostgreSQL databasesby running helm install
three times with a different release name.
Release Number (Release Version)
A single release can be updated multiple times. A sequential counter is used totrack releases as they change. After a first helm install
, a release will haverelease number 1. Each time a release is upgraded or rolled back, the releasenumber will be incremented.
Rollback
A release can be upgraded to a newer chart or configuration. But since releasehistory is stored, a release can also be rolled back to a previous releasenumber. This is done with the helm rollback
command.
Importantly, a rolled back release will receive a new release number.
Operation | Release Number |
---|---|
install | release 1 |
upgrade | release 2 |
upgrade | release 3 |
rollback 1 | release 4 (but running the same config as release 1) |
The above table illustrates how release numbers increment across install,upgrade, and rollback.
Helm Library (or SDK)
The Helm Library (or SDK) refers to the Go code that interacts directly with theKubernetes API server to install, upgrade, query, and remove Kubernetesresources. It can be imported into a project to use Helm as a client libraryinstead of a CLI.
Repository (Repo, Chart Repository)
Helm charts may be stored on dedicated HTTP servers called chart repositories(repositories, or just repos).
A chart repository server is a simple HTTP server that can serve an index.yaml
file that describes a batch of charts, and provides information on where eachchart can be downloaded from. (Many chart repositories serve the charts as wellas the index.yaml
file.)
A Helm client can point to zero or more chart repositories. By default, Helmclients are not configured with any chart repositories. Chart repositories canbe added at any time using the helm repo add
command.
Values (Values Files, values.yaml)
Values provide a way to override template defaults with your own information.
Helm Charts are “parameterized”, which means the chart developer may exposeconfiguration that can be overridden at installation time. For example, a chartmay expose a username
field that allows setting a user name for a service.
These exposed variables are called values in Helm parlance.
Values can be set during helm install
and helm upgrade
operations, either bypassing them in directly, or by using a values.yaml
file.