Helm is a client and server type of application. We'll start with a client. Once we have it running, we'll use it to install the server (Tiller) inside our newly created cluster.
The Helm client is a command-line utility responsible for the local development of Charts, managing repositories, and interaction with the Tiller. Tiller server, on the other hand, runs inside a Kubernetes cluster and interacts with Kube API. It listens for incoming requests from the Helm client, combines Charts and configuration values to build a release, installs Charts and tracks subsequent releases, and is in charge of upgrading and uninstalling Charts through interaction with Kube API.
I'm sure that this brief explanation is more confusing than helpful. Worry not. Everything will be explained soon through examples. For now, we'll focus on installing Helm and Tiller.
If you are a macOS user, please use Homebrew (https://brew.sh/) to install Helm. The command is as follows.
1 brew install kubernetes-helm
If you are a Windows user, please use Chocolatey (https://chocolatey.org/) to install Helm. The command is as follows.
1 choco install kubernetes-helm
Finally, if you are neither Windows nor macOS user, you must be running Linux. Please go to the releases (https://github.com/helm/helm/releases) page, download tar.gz file, unpack it, and move the binary to /usr/local/bin/.
If you already have Helm installed, please make sure that it is newer than 2.8.2. That version, and probably a few versions before, was failing on Docker for Mac and Windows.
Once you're done installing (or upgrading) Helm, please execute helm help to verify that it is working.
We are about to install Tiller. It'll run inside our cluster. Just as kubectl is a client that communicates with Kube API, helm will propagate our wishes to tiller which, in turn, will issue requests to Kube API.
It should come as no surprise that Tiller will be yet another Pod in our cluster. As such, you should already know that we'll need a ServiceAccount that will allow it to establish communication with Kube API. Since we hope to use Helm for all our installation in Kubernetes, we should give that ServiceAccount very generous permissions across the whole cluster.
Let's take a look at the definition of a ServiceAccount we'll create for Tiller.
1 cat helm/tiller-rbac.yml
The output is as follows.
apiVersion: v1
kind: ServiceAccount
metadata:
name: tiller
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: tiller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: tiller
namespace: kube-system
Since by now you are an expert in ServiceAccounts, there should be no need for a detailed explanation of the definition. We're creating a ServiceAccount called tiller in the kube-system Namespace, and we are assigning it ClusterRole cluster-admin. In other words, the account will be able to execute any operation anywhere inside the cluster.
You might be thinking that having such broad permissions might seem dangerous, and you would be right. Only a handful of people should have the user permissions to operate inside kube-system Namespace. On the other hand, we can expect much wider circle of people being able to use Helm. We'll solve that problem later in one of the next chapters. For now, we'll focus only on how Helm works, and get back to the permissions issue later. Let's create the ServiceAccount.
1 kubectl create 2 -f helm/tiller-rbac.yml 3 --record --save-config
We can see from the output that both the ServiceAccount and the ClusterRoleBinding were created.
Now that we have the ServiceAccount that gives Helm full permissions to manage any Kubernetes resource, we can proceed and install Tiller.
1 helm init --service-account tiller 2 3 kubectl -n kube-system 4 rollout status deploy tiller-deploy
We used helm init to create the server component called tiller. Since our cluster uses RBAC and all the processes require authentication and permissions to communicate with Kube API, we added --service-account tiller argument. It'll attach the ServiceAccount to the tiller Pod.
The latter command waits until the Deployment is rolled out.
We could have specified --tiller-namespace argument to deploy it to a specific Namespace. That ability will come in handy in one of the next chapters. For now, we omitted that argument, so Tiller was installed in the kube-system Namespace by default. To be on the safe side, we'll list the Pods to confirm that it is indeed running.
1 kubectl -n kube-system get pods
The output, limited to the relevant parts, is as follows.
NAME READY STATUS RESTARTS AGE ... tiller-deploy-... 1/1 Running 0 59s
Helm already has a single repository preconfigured. For those of you who just installed Helm for the first time, the repository is up-to-date. On the other hand, if you happen to have Helm from before, you might want to update the repository references by executing the command that follows.
1 helm repo update
The only thing left is to search for our favorite application hoping that it is available in the Helm repository.
1 helm search
The output, limited to the last few entries, is as follows.
... stable/weave-scope 0.9.2 1.6.5 A Helm chart for the Weave Scope cluster visual... stable/wordpress 1.0.7 4.9.6 Web publishing platform for building blogs and ... stable/zeppelin 1.0.1 0.7.2 Web-based notebook that enables data-driven, in... stable/zetcd 0.1.9 0.0.3 CoreOS zetcd Helm chart for Kubernetes
We can see that the default repository already contains quite a few commonly used applications. It is the repository that contains the official Kubernetes Charts which are carefully curated and well maintained.
Later on, in one of the next chapters, we'll add more repositories to our local Helm installation. For now, we just need Jenkins, which happens to be one of the official Charts.
I already mentioned Charts a few times. You'll find out what they are soon. For now, all you should know is that a Chart defines everything an application needs to run in a Kubernetes cluster.