Helm Concepts

Internal

• Helm

Chart

Helm Glossary - Chart

A chart is a Helm package, the Kubernetes equivalent of a yum RPM file or a Homebrew formula. A chart contains all resource definitions necessary to deploy and run an application inside Kubernetes.

Chart Installation

Charts are installed into a target Kubernetes cluster and turned into releases with helm install. The installation is an asynchronous process, the Helm client does not wait until all resources are running before it exits, this is because charts may require large Docker images that take long to install in the cluster. Without additional input, a chart will be installed with the default configuration, but custom configuration changes can be applied during the installation process.

The default option for the helm install command is to install from the default repository. However, the chart may come from other sources: a different repository, a local file, an unpacked chart directory or a URL.

Chart Configuration

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 options can be overridden by providing a YAML-formatted file that is then passed during installation with the helm install -f|--values flag.

Chart Layout

archaeopteryx
   |
   |- Chart.yaml
   |
   |- values.yaml
   |
   |- .helmignore
   |
   |- charts
   |
   +- templates

Developing Custom Charts

The development of a custom chart could start with helm create, which is a command that creates a standard chart directory layout along with some common files typically used in a chart. The command provides just a basic example and is not meant to cover all Kubernetes resources.

TODO: https://helm.sh/docs/developing_charts/.

Chart Operations

• helm install
• helm inspect
• helm create

Repository

Helm Glossary - Repository

A repository is a place where charts are collected and shared. A repository must expose an index.yaml in its root. When Helm is installed, it is pre-configured with a default repository. New repositories an be added. Repositories can be searched for charts with helm search. Because chart repositories change frequently, it is recommended to update the local cache.

Default Repository

When Helm is installed, it is pre-configured to look into the official Kubernetes chart repository, named "stable".

Repository Operations

• helm repo
• helm search

Release

Helm Glossary - Release

A release is a running instantiation of a chart, to which a specific config was applied. Whenever a chart is installed, a new release is created. One chart can be installed multiple times into the same cluster, and each can be independently managed and upgraded. Each release has its own release name.

When a new version of a chart is released, or when the configuration of a release must be changes, the release can be upgraded with helm upgrade. Helm tries to perform the least invasive upgrade, and only upgraded things that changed since the last release. If something fails during the upgrade, a rollback can be performed with helm rollback.

Releases can be of course uninstalled, or deleted with helm delete. Helm keeps a history of deleted releases, which can be retrieved with helm list --deleted.

Release Name

If not specified, release names are generated (e.g. "happy-panda"). To specify a release name, use helm install --name. Helm keeps records of deleted releases, so a release name first used by a deleted release cannot be re-used (unless --replace is used).

Release Revision

A release version (revision) is incremental. Every time an install, upgrade or rollback happens, the revision number is incremented by 1, and the first revision is always 1. The revision numbers for a certain release can be inspected with helm history. A release revision can be used during a rollback.

Release Operations

• helm install
• helm get
• helm list
• helm history
• helm status
• helm upgrade
• helm rollback
• helm delete

Dependency

• If I rely on a dependency referred from an external Helm repository, and the repository exposes newer versions, can I still rely on the fact that the old version is still available? I might not want to upgrade to the "latest", but keep using a version I tested with and was proven stable.

Runtime

The Helm Client

The client is responsible for managing charts.

The Tiller Server

The server is responsible for managing releases.

Tiller stores release information in ConfigMaps in the namespace where it is running. It could be configured to use a storage backend that uses Secrets for storing release information. More here. It could also be configured to use an SQL storage backend for storing release information. More here.

Security

Security Concepts