What Rancher Server does and how it works? — Series II
Why?
I have told you that I’ll be sharing a new story every Sunday and I kept my promise. If you haven’t read the previous post and want to know how we did choose Rancher Server in our scenario, please read this first and understand the reasons completely.
In this Series II, we’ll talk about what Rancher Server does for us, how it handles the management of the underlying infrastructure by automated provisioning and what we gain from it.
Rancher Server is a very lightweight and powerful tool to deploy and orchestrate multiple Kubernetes (K8s) clusters, both on-premises and the cloud.
The overall Rancher Server architecture can be described as below.
You should never mix Rancher Server and Rancher Kubernetes Engine (RKE) concepts. They are completely different things. You can keep using Rancher Server to manage your Kubernetes clusters that provisioned using Rancher Server, without the obligation of using Rancher’s own Kubernetes Platform.
Do you know what Docker-Machine is?
I wonder if any of the readers have used Docker-Machine before? It’s a project Docker made around 5 years ago, and just like Docker Swarm, it has f#cked and not maintained anymore.
In basic terms, Docker-Machine was a way to create/provision Virtual Machine’s (VM) on several platforms with a pre-installed and configured Docker Engine.
It was so simple, yet powerful.
How about Rancher-Machine?
Well, after Docker-Machine lost it’s maintainability even with all there is to provide, Rancher decided to fork (basically adopted, rather than letting it die) the project 2–3 years ago and continued improving it under a very similar, the Rancher-Machine name.
Additional features included in the Rancher-Machine, is that the upstream support for destination platforms keeps maintained and the Rancher-Machine is embedded inside the Rancher Server.
vSphere Cluster Lifecycle Management
As you might guess from the Series I, one great, simple solution was needed for VMware vSphere in our case. Both because VMware is a great hypervisor and Rancher is a powerful on-premise cluster provisioner.
Node Templates
Rancher Server provides us a template option called Node Templates. In these templates, we provide specific details about how our VMs should be provisioned. This includes how much CPU or Memory we’re going to need or which version of Docker is required to install.
In my consideration, you should create different Node Templates depending on the group of nodes you think you’ll be provisioning.
I decided to create two (2) different templates for my use case, as one for Master nodes and the other one for Worker nodes. Of course, I can expand it to three (3) or four (4) depending on the extension of my cluster.
To elaborate more, at this point I’m depending on the default vSphere Cloud Provider to provision my Persistent Volume Claims (PVC) natively. But in this way it blocks me to provision an NFS Persistent Volume (PV) as it’s not supported in the driver I use yet. So, I can’t provision any ReadWriteMany PVs natively. If I need such feature in the near future, I would have to deploy Ceph or GlusterFS as a secondary StorageClass.
To do that, I would prefer making a separate Node Template called StorageTemplate and deploy any storage related management resources there. Which helps me organize stuff in the end.
You got the gist I think…
As much as Rancher-Machine simplifies the provisioning process, Rancher Server still needs some information/credential regarding the provisioned VMs, so that it is able to use this information to manage the VMs or continue the cluster bootstrapping process by installing K8s.
To do so, Rancher bootstraps an SSH Key into these VMs using cloud-init.
So at the end, the way Rancher Server provisions everything as below:
Provisioning with Different Operating Systems
So far in the templates, we assumed using the default RancherOS alone would suffice all our needs. You can confidently run RancherOS for your production workloads and it’s all fine.
However, if you think that is not enough for you, or you would like to tailor your base operating system, you should make your own Golden Image and for that purpose Rancher recommends that you use Packer.
In-Tree and Out-of-Tree Cloud Provider
We have mentioned about Cloud Providers a lot previously. In very simple terms, it’s a module inside K8s that links your cluster into your cloud provider’s API.
Example native cloud providers built into K8s code are:
- AWS
- Azure
- GCP
- vSphere
- OpenStack, etc.
In-Tree (Legacy)
Logic and context of each cloud provider is embedded into most of the K8s components. For example, kubelet requesting information via a metadata service from the cloud provider.
I am using In-Tree method as my current VMware environment is not upstream version to support Out-of-Tree cloud provider.
Out-of-Tree
The logic in this method resides outside the K8s components, typically as deployed workloads. Decoupled from the K8s code, developed and maintained independently.
So, you can think of this method as the way cloud providers make their own K8s resources to talk with their own APIs.
If you have some time to spare, you can watch this 1 hour and 26 minutes of Kubernetes Master Class lab video to reinforce your readings.
As you can imagine, using Rancher helps a lot to keep management burden at minimum. It helps us provision VMs the way we want and doing all the nasty things, helps us authenticate people in a way to manage different type of clusters, and it is really reliable.
That’s about right to sum it up. See you in the Series III, which is about Installing and Configuring the Rancher Server, Day 0 and following operations.
Thank you for reading.
