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-helmInitialize Helm and install the Tiller service (with kubectl preconfigured)
helm initFor 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 updateTo 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 -pFor 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.yamlOne 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/directoryUsing
requirements.yamlandhelm dep up foochartto 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:
Popular Helm Plugins
helm-tiller - Additional commands to work with Tiller
Technosophos's Helm Plugins - Plugins for GitHub, Keybase, and GPG
helm-template - Debug/render templates client-side
Helm Value Store - Plugin for working with Helm deployment values
Drone.io Helm Plugin - Run Helm in the Drone CI/CD system
最后更新于