Helm

Helm is to Kubernetes what package managers like yum/apt/homebrew are to traditional operating systems. It leverages Charts to handle Kubernetes manifest files.

Basic Usage of Helm

To install the helm client, simply input

brew install kubernetes-helm

Initialize Helm and install the Tiller service (with kubectl preconfigured)

helm init

For Kubernetes versions v1.16.0 and above, you may encounter an Error: error installing: the server could not find the requested resource. This results from extensions/v1beta1 being replaced by apps/v1. The resolution is

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

To update the charts list

helm repo update

To deploy a service, such as MySQL

  ~ helm install stable/mysql
NAME:   quieting-warthog
LAST DEPLOYED: Tue Feb 21 16:13:02 2017
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Secret
NAME                    TYPE    DATA  AGE
quieting-warthog-mysql  Opaque  2     1s

==> v1/PersistentVolumeClaim
NAME                    STATUS   VOLUME  CAPACITY  ACCESSMODES  AGE
quieting-warthog-mysql  Pending  1s

==> v1/Service
NAME                    CLUSTER-IP    EXTERNAL-IP  PORT(S)   AGE
quieting-warthog-mysql  10.3.253.105  <none>       3306/TCP  1s

==> extensions/v1beta1/Deployment
NAME                    DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
quieting-warthog-mysql  1        1        1           0          1s


NOTES:
MySQL can be accessed via port 3306 on the following DNS name from within your cluster:
quieting-warthog-mysql.default.svc.cluster.local

To get your root password run:

    kubectl get secret --namespace default quieting-warthog-mysql -o jsonpath="{.data.mysql-root-password}" | base64 --decode; echo

To connect to your database:

1. Run an Ubuntu pod that you can use as a client:

    kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il

2. Install the mysql client:

    $ apt-get update && apt-get install mysql-client -y

3. Connect using the mysql cli, then provide your password:
    $ mysql -h quieting-warthog-mysql -p

For more usage of commands, refer to the "Helm Command Reference" section below.

How Helm Works

Basic Concepts

Helm centers around three concepts:

  • Chart: A Helm application (package), consisting of all associated Kubernetes manifest templates. Analogous to YUM RPM or Apt dpkg files.

  • Repository: The storage depot for Helm packages.

  • Release: The deployment instance of a chart. Each chart can deploy one or multiple releases.

Working Principle of Helm

Helm comprises two components: helm client and tiller server.

The client is responsible for managing charts, while the server handles release management.

helm client

The helm client is a command-line tool responsible for the management of charts, repositories, and releases. It communicates with tiller via a gPRC API (this is done via 'kubectl port-forward' to map tiller's port to the local machine, then communicate with tiller through the mapped port), sending commands for tiller to manage corresponding Kubernetes resources.

Usage of helm commands can be found in the "Helm Command Reference" section below.

tiller server

Tiller receives requests sent from the helm client and relays the resource operations to Kubernetes, managing (installing, querying, upgrading, or deletion, etc.) and tracking the Kubernetes resources. To facilitate this, tiller saves release-specific information in Kubernetes ConfigMap.

Tiller exposes a gRPC API for the helm client to call.

Helm Charts

Helm employs Charts to manage Kubernetes manifest files. Each chart minimally includes:

  • Basic information of the application Chart.yaml

  • One or more Kubernetes manifest file templates (stored under templates/ directory), encompassing various Kubernetes resources such as Pod, Deployment, Service, and so on.

Chart.yaml Example

Dependency Management

There are two main ways in which Helm manages dependencies:

  • Directly placing dependent packages in charts/ directory

  • Using requirements.yaml and helm dep up foochart to automatically download dependent packages

Chart Templates

Chart templates are built upon Go templates and Sprig, for instance,

The default values for template parameters should be placed in values.yaml file, with the format:

Helm Plugins

Plugins offer a way to extend the functionality of Helm. They are executed on the client side and located in $(helm home)/plugins directory.

A typical format of a Helm plugin is:

and the format of plugin.yaml is:

In this manner, the command helm keybase can be used to call this plugin.

Helm Command Reference

Querying Charts

Retrieving Package Details

Deploying Packages

Options for packages can also be customized before deployment:

Moreover, you can deploy apps through a package file (i.e., .tgz) or local package path (e.g., path/foo).

Listing Services (Releases)

Checking Service (Release) Status

Upgrading and Rolling Back Releases

Deleting Releases

Repository Management

Chart Management

Helm UI

Kubeapps provides an open-source Helm UI interface, making Helm application management in a graphical interface possible.

For additional usage instructions, please refer to the Kubeapps official website.

Helm Repository

Official repositories:

Third-party repositories:

  1. helm-tiller - Additional commands to work with Tiller

  2. Technosophos's Helm Plugins - Plugins for GitHub, Keybase, and GPG

  3. helm-template - Debug/render templates client-side

  4. Helm Value Store - Plugin for working with Helm deployment values

  5. Drone.io Helm Plugin - Run Helm in the Drone CI/CD system

最后更新于