Running a simple instance of your application with Docker, is just one command away. But have you ever thought of how this would behave in a production like environment? If you wish to scale your application based on the load, what would be the best approach? Just assume that you have a user base of 10k users and you want to scale your application to support the load. You will definitely have to worry about the following.
How to deploy a Load Balancer (LB)
How to configure the LB to manage the containers
How to create replicas on demand when load is high
How to make all containers connected, to communicate with each other
How can you think of sharing data between containers?
These are all problems that you will come across when taking your application into a production environment. This is where container orchestration plays a major role. In this article I would like to talk about Container Orchestration with Kubernetes for Docker containers. If you are not familiar with the concept of Docker, please read my previous article on Docker. I will briefly touch on the core concepts of Kubernetes and how we can use it to deploy our applications in a production like environment. Not only that, I would also talk a little bit about Docker Swarm and compare existing Container Orchestration tools in the market.
What is Container Orchestration?
Let us first try and understand why we need container orchestration in the first place. Docker is one of the most famous platforms for containers and to ship production applications from environment to environment. Handling a handful of containers is not a big problem. But when it comes to thousands of containers and multiple services, how are you planning on connecting them into a single logical unit to work together? This is one of the toughest problems with distributed systems, where there are different mechanisms to solve problems like this based on the requirement.
When having a handful of containers, it was all about bringing up a couple of DevOps engineers to monitor and maintain the production system. But, can you do the same when you are operating at a larger scale? Can you have engineers to deploy new containers and connect them together when the load is high? This is why you need container orchestration. This will let you automate the entire process of deploying, managing, monitoring, networking and managing the availability of your containers the way you want.
Container orchestration will provide you plenty of features to run the application in a production like environment.
Monitor the redundancy and availability of containers
Provisioning and deployment of containers
Resource allocation
Configuration and scheduling of containers
Scaling or removing containers based on balancing workloads across your infrastructure
Monitoring the health of containers
Load balancing and routing traffic
Handling secure network communications between containers
Handle which containers and hosts, will run user provided applications
External exposure of services, running in a container with the outside world
Monitor the health of the Docker host and move containers
Easily update containers with zero downtime
Sharing storage between containers and hosts
Solutions Available for Container Orchestration
Docker Swarm
Docker Swarm is an application provided by Docker itself for the purpose of container orchestration. This is simple and very easy get started with. But, it lacks some of the auto scaling features required for complex, production like applications. In this section I would like to cover some basics of Docker Swarm so that you get a clear idea on what it is.
With Docker Swarm, you can combine multiple Docker hosts, into a single cluster. In this cluster, you need multiple machines with Docker installed on them, and one machine needs to be the Swarm Manager, whereas the rest becomes Workers.
Next, you can select any machine to be your Swarm Manager. Go and run the following command on it to initialise the set up.
> docker swarm init
With this command, you will see the instructions on how to get your Docker workers to join the Swarm Manager. The command should look like the following.
> docker swarm join --token <token>
Next, you do not have to worry about the Worker nodes. The rest of the commands should run on the Swarm Manager Node. Run the following command on the Manager node to deploy 100 containers at once.
> docker service create --replicas=3 <image-name>
I hope you get a clear idea on how Docker Swarm works. More on this can be addressed in a different article. Next, let's understand all we need to know about Kubernetes.
Introduction to Kubernetes
Kubernetes (also known as K8s) is an Open Source container orchestration tool which automates container deployment, container scaling/de-scaling and container load balancing. So Kubernetes will be managing your docker containers in a production like manner.
Kubernetes is written in GoLang, and it has a huge open source community, where Google first developed it and made it available to the general public later on. The basic idea is, it will group all your containers into one logical unit for the management of those containers.
The following table shows the differences between Kubernetes and Docker Swarm.
Similar to Docker Swarm, Kubernetes also has a Master Node where all the Kubernetes control tools are installed.
When you install Kubernetes, you also install another set of tools along with it.
> API Server - the application interface for Kubernetes. If you wish to interact with Kubernetes cluster, everyone has to talk to the API server.
> etcd - This is a distributed reliable key value store. This stores all data used to manage the cluster. This information is not stored on a single machine. It is stored on multiple machines in a distributed manner.
> Scheduler - This is responsible for distributing containers across nodes.
> Controllers - This is the brain behind the orchestration. This is responsible for informing when nodes, containers or endpoints go down. Basically, this is responsible for making sure that the shared state of the cluster is operating as expected.
> Container Runtime - This is the underlying runtime used to run containers. For example, it could be Docker.
>Kube proxy - The Kube proxy routes traffic coming into a node from the service. It forwards requests for work to the correct containers.
> kubelet - This is the agent that runs on each node in the cluster. These are responsible for checking whether the nodes are running in the containers as expected.
> Kubernetes Master - This is responsible for scheduling and deploying application nodes across nodes. This talks to the cluster via the API server mentioned above.
But one thing to note here is, the Kubernetes Master does not run any containers on itself, whereas in Docker Swarm, the Swarm Manager will have containers running on its host as well.
In Kubernetes, all the containers will be running only on the nodes. If you wish to create your own Kubernetes Cluster, you need to follow the following order.
Create the Master
Then get the Nodes to Join the Cluster
If you wish to access or communicate with your "Kubernetes Master", you can use the CLI or the Ui provided by Kubernetes. Via the CLI, you can enable the UI (Dashboard). Then you can access the Master via the UI.
How Kubernetes works
The image above shows, how the nodes behave along with the Master in a Kubernetes Cluster. The Kubernetes Master is responsible for controlling all the nodes. As you can see, each node contains PODs and each POD contains Containers. These containers act as replicas where they serve to load balance the incoming requests.
The relation between Docker and Kubernetes is, the fact that Kubernetes uses Docker hosts to run the Docker containers. It need not be Docker containers all the time. It also support other alternatives like Rocket.
In this section, I will explain the basic terminology and the architecture of how Kubernetes work.
Let us go through some of the terminology used in Kubernetes
Nodes
A Node can be considered to be an actual physical machine or a virtual machine. Inside a Node, there are multiple PODs running. When you're operating at scale, you want to be able to hand work over to a node whose pods are free to take it.
Pods
A POD is considered to be the smallest unit that Kubernetes can administer. Each POD has its own resources which is shared by the containers running inside it, and it has a single IP address that can be used by outsiders to communicate.
It’s quite common to have a pod with only a single container, when the application or service is a single process that needs to run. But when things get more complicated, and multiple processes need to work together using the same shared data volumes for correct operation, multi-container pods ease deployment configuration compared to setting up shared resources between containers on your own.
Basic Commands on KubeCTL
The same way you use the Docker run command, Kubernetes provides you with a different application called the "Kubernetes Controller" or "kubectl", which you can use to run multiple nodes across a Kubernetes cluster. With the following command, you can run 1000 containers in a single command.
> kunectl run --replicas=1000 <application-name>
If you wish to scale your application up to 2000 containers, you can run the following command,
> kubectl scale --replicas=2000 <application-name>
If you wish to update the application with a newer image(a different version from what is deployed), you can do it in a Rolling Update mechanism, where you update one container at a time.
> kubectl rolling-update <application-name> --image=new-image:2
If something goes wrong, you can simply Roll Back in a manner, where you Rollback one by one of the containers.
> kubectl rolling-update <application-name> --rollback
View information about the cluster.
> kubectl cluster-info
List all the nodes in the cluster.
> kubectl get nodes