Up next in 10
Install Rancher 2 w/ Terraform & Ansible - Part #13 - Installing Tiller On Your Kubernetes Cluster
37K views
Feb 14, 2023
Now we need to install Tiller on our cluster. We have done almost all the hard work. What remains is to set up a shell script to achieve the following: * Create the ServiceAccount in the kube-system namespace. * Create the ClusterRoleBinding to give the tiller account access to the cluster. * Finally use helm to install the tiller service
View Video Transcript
0:00
In this video, we're going to install Tiller on our cluster
0:03
and Tiller is the in-cluster component of Helm. Now, Helm is a bit like Composer in PHP
0:10
It is, in essence, the package manager for Kubernetes. Now, Helm is the name of the wider project
0:15
but it's also the name of the command line client, which we will use, but we'll need Tiller on the remote cluster
0:22
in order for Helm commands to work. Initially, at least, there are three steps that we need to complete
0:27
and these are documented on the Rancher Docks. We're going to need to create the service account in the Cube System namespace
0:33
create the cluster roll binding to give Tiller account access to the cluster, and then use Helm to install the Tiller service
0:40
And we'll make this a one-step process by creating ourselves a shell script
0:44
The contents of this shell script are essentially what you see on screen at the moment
0:49
So we can take a quick copy of them. Now, much like we've done for pretty much every command that we've run inside this project
0:55
I'm going to use a Docker image for Helm. For this, I'm going to make use of Linkyard's Docker Helm image
1:02
Much like CoobCtl, the Helm command will also need access to our
1:06
CubeConfig Rancher Cluster YAML file, so I'm going to add that in as a volume
1:11
Whilst absolutely not essential I going to change the volume mapping to make it more visible at a scan that we talking about Helm here because this command looks very very similar to the Cube CTL command above So I already said that we going to use Linkyard Docker Helm image
1:28
and it's always worth looking at the Docker file for these images, as you can learn quite a lot of cool stuff
1:33
And in this particular example, this image uses a multi-stage build, which is a really advanced concept
1:39
It's very cool concept. It's not something that we're going to go into here. It's a particularly interesting topic
1:45
that you end up with multiple Docker files in your project, maybe one for production, one for development, and so on
1:51
Back in our make file, we'll make use of link yard Docker Helm for this particular command
1:56
and we'll also set the Kube Config, and I've made a slight mistake here by just copying and pasting
2:01
As I said earlier, perhaps you don't need to change the path. I just find that at a quick visual scan, it makes it more obvious that these two commands
2:09
the Helm and the Kube CTL command, are different. Anyway, with the Helm command available to us, we can now get on with the process that was documented on the Rancho Docs
2:19
And as mentioned earlier, I'm going to put this into its own shell script, just for ease of use, really
2:24
Inside the shell script, I'll start off with the Shibang, and then I'm going to paste in the three commands that I found on the Ranch documentation
2:30
We'll be able to use these as a base of reference, but our commands will look slightly different
2:35
So for each of these entries we going to make Cube CTL setting our command variable to whatever comes after the cube CTL command Pretty straightforward and in doing so we dockerized all three of those helm commands
2:48
These commands are not idempotent which means if we run them multiple times we may get an error if the command is already successfully completed
2:56
The truth of the matter is you're probably not going to run these commands particularly often
3:01
This really should only be initial setup sort of stuff. The thing is, I am going to hit on some errors because I've made that typo in the Cube config
3:09
Anyway, always interesting to see. Now again, an optional step here. I'm going to add install Tiller on the cluster as a make file command
3:16
Really, this is just going to directly reference that shell script. You could, of course, just run the shell script directly from the command line
3:22
but I like to use the make file in such a way that it kind of documents all the different things that I can do inside my projects
3:29
This becomes really helpful, like a few months later when you come back to look at your project
3:33
and you've forgotten everything. When we run that shell script, because this is the first time
3:37
the Helm image has been used, it first gets pulled down, and then it tries to run through the commands
3:43
But of course, I have that typo in the cube config, so I need to correct that first
3:47
Hopefully, you didn't make the same mistake. And with that change to the configuration made
3:52
if I rerun the shell script, we going to see some errors in the output and again this comes back to the idempotency issue This is not a critical problem it just never nice to see errors when you running commands now there an interesting gotcha here
4:06
again because we're using docker we'll come back to that in a moment but the end of this we do see
4:11
a successful outcome and if we check the rollout status of the tiller deployment we can see that
4:16
this completed successfully there's a really common gotcha when using docker for running commands
4:22
in this way and that's that if the command creates any file
4:25
those files are going to end up inside the resulting container. And unless we've explicitly mapped a volume to ensure those files end up on our local disk
4:35
then they're going to remain in the container. And in our case, when the container is removed, so are the files
4:41
In our case, the init service account tiller command is going to create a bunch of files inside slash root
4:48
And so we want those files to stick around after the container exits
4:52
And with that final addition to the Helm command, when we run the install tiller on Cluster ShellScript
4:58
we should end up with all of those expected Helm configuration files residing on our local disk
5:05
This is a really important step, as you can probably imagine, because we need those files for each subsequent time that we run Helm
5:11
With all this configuration in place, we can get started telling Helm about our first Helm chart
5:16
and that's going to be the Rancher Helm chart. So we'll get onto that in the very next video