The Kubernetes Helm Architecture

This document describes the Helm architecture at a high level.

The Purpose of Helm

Helm is a tool for managing Kubernetes packages called charts. Helmcan do the following:

  • Create new charts from scratch
  • Package charts into chart archive (tgz) files
  • Interact with chart repositories where charts are stored
  • Install and uninstall charts into an existing Kubernetes cluster

  • Manage the release cycle of charts that have been installed with HelmFor Helm, there are three important concepts:

  • The chart is a bundle of information necessary to create aninstance of a Kubernetes application.

  • The config contains configuration information that can be mergedinto a packaged chart to create a releasable object.
  • A release is a running instance of a chart, combined with aspecific config.

Components

Helm has two major components:

The Helm Client is a command-line client for end users. The clientis responsible for the following domains:

  • Local chart development
  • Managing repositories

  • Interacting with the Tiller server

    • Sending charts to be installed
    • Asking for information about releases
    • Requesting upgrading or uninstalling of existing releasesThe Tiller Server is an in-cluster server that interacts with theHelm client, and interfaces with the Kubernetes API server. The serveris responsible for the following:

  • Listening for incoming requests from the Helm client

  • Combining a chart and configuration to build a release
  • Installing charts into Kubernetes, and then tracking the subsequentrelease
  • Upgrading and uninstalling charts by interacting with KubernetesIn a nutshell, the client is responsible for managing charts, and theserver is responsible for managing releases.

Implementation

The Helm client is written in the Go programming language, and uses thegRPC protocol suite to interact with the Tiller server.

The Tiller server is also written in Go. It provides a gRPC server toconnect with the client, and it uses the Kubernetes client library tocommunicate with Kubernetes. Currently, that library uses REST+JSON.

The Tiller server stores information in ConfigMaps located inside ofKubernetes. It does not need its own database.

Configuration files are, when possible, written in YAML.