Helm installation: Difference between revisions

From WilliamsNet Wiki
Jump to navigation Jump to search
(Created page with "== Installing Helm == There are two parts to Helm: The Helm client (helm) and the Helm server (Tiller). Every [https://github.com/helm/helm/releases release] of Helm provide...")
 
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
Helm advertises itself as "the package manager for kubernetes" -- comparing itself with RedHat/CentOS 'yum' or 'dnf' commands and Debian/Ubuntu 'apt-get'.  The comparison is valid, but the reality is that helm leaves a lot to be desired as a full package manager and needs a lot of work before it becomes as commonplace as those other tools.
While helm v2.x required the privileged 'tiller' process to be active in the kubernetes cluster to do it's dirty work, the hue and cry over this obvious security ''faux pax'' was loud enough to force a redesign for v3.x that does not require such a crutch.
== Installing Helm ==
== Installing Helm ==
There are two parts to Helm: The Helm client (helm) and the Helm server (Tiller).  
The redesigned helm v3 only requires a client executable to be installed on whichever system where package installations will be initiated.


Every [https://github.com/helm/helm/releases release] of Helm provides binary releases for a variety of OSes. These binary versions can be manually downloaded and installed.
Every [https://github.com/helm/helm/releases release] of Helm provides binary releases for a variety of OSes. These binary versions can be manually downloaded and installed.
Line 6: Line 10:
# Download your [https://github.com/helm/helm/releases desired version]
# Download your [https://github.com/helm/helm/releases desired version]
# Unpack it (tar -zxvf helm-v2.0.0-linux-amd64.tgz)
# Unpack it (tar -zxvf helm-v2.0.0-linux-amd64.tgz)
# Find the helm binary in the unpacked directory, and move it to its desired destination (mv linux-amd64/helm /usr/local/bin/helm)
# Find the helm binary in the unpacked directory, and move it to its desired destination:
mv linux-amd64/helm /usr/local/bin/helm


From there, you should be able to run the client: helm help.
From there, you should be able to run the client: helm help.


== Installing Tiller ==
The only other action required is to install a repo for it to pull packages from:
Tiller, the server portion of Helm, typically runs inside of your Kubernetes cluster.
 
We will install tiller so that it has explicit RBAC access -- using a service account that we create that has cluster-admin privileges.  It is just as easy to use a service account with more restricted permissions (say, just for a given namespace) to reduce the security exposure.


First -- define the service account using this in the file rbac-config.yaml:
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
<pre>apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system</pre>


create the service account:
Note that the repo is stored locally on the system where the command was issued, not in the cluster itself.  Validate that the installation was successful by listing the available packages:


  $ kubectl create -f rbac-config.yaml
  helm search repo stable
serviceaccount "tiller" created
clusterrolebinding "tiller" created
$ helm init --service-account tiller --history-max 200


This file and instructions are contained in the [https://gitlab.williams-net.org/k8s/k8s-admin GitLab k8s-admin repository].  These instructions were condensed from the [https://helm.sh/docs/using_helm/#installing-helm helm online documentation].
These instructions were condensed from the [https://helm.sh/docs/intro/quickstart/ helm quickstart guide].

Latest revision as of 11:11, 19 October 2021

Helm advertises itself as "the package manager for kubernetes" -- comparing itself with RedHat/CentOS 'yum' or 'dnf' commands and Debian/Ubuntu 'apt-get'. The comparison is valid, but the reality is that helm leaves a lot to be desired as a full package manager and needs a lot of work before it becomes as commonplace as those other tools.

While helm v2.x required the privileged 'tiller' process to be active in the kubernetes cluster to do it's dirty work, the hue and cry over this obvious security faux pax was loud enough to force a redesign for v3.x that does not require such a crutch.

Installing Helm[edit]

The redesigned helm v3 only requires a client executable to be installed on whichever system where package installations will be initiated.

Every release of Helm provides binary releases for a variety of OSes. These binary versions can be manually downloaded and installed.

  1. Download your desired version
  2. Unpack it (tar -zxvf helm-v2.0.0-linux-amd64.tgz)
  3. Find the helm binary in the unpacked directory, and move it to its desired destination:
mv linux-amd64/helm /usr/local/bin/helm

From there, you should be able to run the client: helm help.

The only other action required is to install a repo for it to pull packages from:

helm repo add stable https://kubernetes-charts.storage.googleapis.com/

Note that the repo is stored locally on the system where the command was issued, not in the cluster itself. Validate that the installation was successful by listing the available packages:

helm search repo stable

These instructions were condensed from the helm quickstart guide.