Helm Glossary

    A Helm package that contains information sufficient for installing a setof Kubernetes resources into a Kubernetes cluster.

    Charts contain a file as well as templates, default values(values.yaml), and dependencies.

    Charts are developed in a well-defined directory structure, and thenpackaged into 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 mayoccur:

    • Soft dependency: A chart may simply not function without another chartbeing installed in a cluster. Helm does not provide tooling for thiscase. In this case, 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 will install all of its dependencies. In thiscase, a chart and its dependencies are managed as a collection. When a chart is packaged (via helm package) all of its hard dependenciesare bundled with it.

    Chart Version

    Charts are versioned according to the . A version number is required on every chart.

    Chart.yaml

    Information about a chart is stored in a special file calledChart.yaml. Every chart must have this file.

    Helm is the package manager for Kubernetes. As an operating systempackage manager makes it easy to install tools on an OS, Helm makes iteasy to install applications and resources into Kubernetes clusters.

    While Helm is the name of the project, the command line client is alsonamed helm. By convention, when speaking of the project, Helm iscapitalized. When speaking of the client, helm is in lowercase.

    Helm Home (HELM_HOME)

    This directory contains configuration and cache data, and is created by.

    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 theplace where 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,notably the helm lint command.

    Provenance (Provenance file)

    Helm charts may be accompanied by a provenance file which providesinformation about 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, anda signature block (an OpenPGP “clearsign” block). When coupled with akeychain, 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
    • Quickly match a chart to its provenance data Provenance files have the .prov extension, and can be served from achart repository server or any other HTTP server.

    When a chart is installed, Tiller (the Helm server) creates a _release_to track that installation.

    A single chart may be installed many times into the same cluster, andcreate many different releases. For example, one can install threePostgreSQL databases by running helm install three times with adifferent release name.

    (Prior to 2.0.0-Alpha.1, releases were called deployments. But thiscaused confusion with the Kubernetes Deployment kind.)

    Release Number (Release Version)

    A single release can be updated multiple times. A sequential counter isused to track releases as they change. After a first , arelease will have release number 1. Each time a release is upgraded orrolled back, the release number will be incremented.

    Rollback

    Importantly, a rolled back release will receive a new release number.

    The above table illustrates how release numbers increment acrossinstall, upgrade, and rollback.

    Tiller

    Tiller is the in-cluster component of Helm. It interacts directly withthe Kubernetes API server to install, upgrade, query, and removeKubernetes resources. It also stores the objects that representreleases.

    Repository (Repo, Chart Repository)

    Helm charts may be stored on dedicated HTTP servers called chartrepositories (repositories, or just repos).

    A chart repository server is a simple HTTP server that can serve anindex.yaml file that describes a batch of charts, and providesinformation on where each chart can be downloaded from. (Many chartrepositories serve the charts as well as the index.yaml file.)

    A Helm client can point to zero or more chart repositories. By default,Helm clients point to the stable official Kubernetes chartrepository.

    Values provide a way to override template defaults with your owninformation.

    Helm Charts are “parameterized”, which means the chart developer mayexpose configuration that can be overridden at installation time. Forexample, a chart may expose a username field that allows setting auser name for a service.

    These exposed variables are called values in Helm parlance.