Today here i will start a new blog, consisting of several parts, to talk about Kubernetes, Rancher and Containers.
It’s a very wide field to talk about, and we will start with the simple things:
Why Containers
Lets make this not so big, there are already thousands of posts outside there.
Just the basic elements.
A container is not a thing, not a packed product. You can see it as code that is executed in a very specific environment that is containing the code and creating barriers around the code. This specific environment can be created by the linux kernel, with a set of tools that the kernel has already long time integrated.
The rise of the containers started with Docker: it was the first easy to use tool that made it possible to set up this containing environment in the kernel easy and that gave us easy to use tools to download ready to use containers or create our own containers and simply use them. They also created a defined image format for containers.
Such images are universal usable: as long as the container engine is installed on top of an OS, the containerised code from the image can run there. The image brings all dependencies with it. So it gives developers an universal environment for their code, they don’t need to care about dependencies on different systems any more.
Containers are perfect for microservices: You break your big monolithic application (that is very hard to maintain) into several pieces, pack the pieces in container and let the containers just communicate with each other so that they can fulfil the task and provide a service to the outworld. The single containers can be managed and maintained much more easy than the big monolithic block.
It’s also possible to pack such big monolithic applications in a container. The advantage of maintaining microservices is lost then. But there can be still other advantages. SAP is for example working on a solution that lets S/4 HANA run in a Kubernetes platform so that they can use High Availability and automatic spawning of instances in case of high load on the SAP platform.
Container Orchestration
So containers with Docker are now already around us several years.
The next challenge was now to maintain multiple containers in a unique platform consisting of multiple servers. First there was Dockers own orchestrating tool for container clusters, Swarm. But in the end Kubernetes was the successor to manage a cluster consisting of multiple nodes that run a high number of containers.
Kubernetes allows us to easy deploy pods (a pod consists of one or more containers running on one node), it allows also to deploy and manage more complex things like a predefined collection of pods that build up service together for the outer world.
Kubernetes manages also the communication between this pods that are deployed across several nodes and how this services are reachable from the outer world.
Updates of such pods, loadbalancing across pods while updating, test deployments and so on are all managed by kubernetes.
So we have now with Kubernetes a solution to handle deployment, lifecycle, availability and load balancing of thousands of pods across hundreds of nodes.
But guess what? It’s still not a sufficient solution!
Why?
Its not easy to deploy a Kubernetes cluster directly from the sources in the internet.
Deploying Kubernetes the hard way directly from github will cost you days of work even if you are an experienced Linux Administrator.
And also the Kubernetes Nodes themselves need maintenance regarding the Node Os and the Kubernetes components. This is also not handled by Kubernetes itself and is manual admin work.
And finally you have with original Kubernetes only a command line interface which works great, but if you want to manage several clusters at different locations with hundreds of nodes and thousands of pods you will loose the big picture view very soon.
That’s where Rancher comes in the game.
Rancher
What is Rancher?
First of all it’s a web based graphical frontend to install and manage Kubernetes clusters and manage Deployments inside this clusters. It’s completely Open Source and free to use. But it’s not only GUI, you have inside of the Rancher GUI still a command line interface to your clusters.
Rancher is designed to be installed in a separate Kubernetes Cluster that is only used for easy deployment and management of so called downstream clusters: they will carry then the workload deployments.
You can deploy Rancher also in a single machine docker environment for testing.
But it’s also a company that was shortly acquired by SUSE. This company does a lot for development of Rancher and offers commercial support for their software.
They provide not only the Rancher software, they provide also several certified Kubernetes distributions like RKE, RKE2 and K3S.
Rancher also build up a ecosystem around their Rancher software that makes it quite easy to deploy extensions to Kubernetes, like for example Longhorn, a distributed storage on the Kubernetes nodes to provide permanent storage for deployments.
Finally it’s quite safe to say that Rancher simplifies deploying and operating Kubernetes clusters a lot and that they are the leading platform to do that.
In the next part of this blog we talk about how an enterprise grade approach can look to use Kubernetes with Rancher, and how you can deploy a test platform that is nearly enterprise grade and can be used with very little changes in a big enterprise environment.