In this series, We will go through one topic that is Kubernetes. We will cover history, Architecture design, Basic concept and then deep dive in each concept. Though there are ton of guide are available for each topic this is kind of comprehensive guide which will try to cover all major topic.
If you are reading this you don’t need an introduction to Kubernetes but every great product has an interesting history it maybe Linux or Git or Google etc. The importance of history is to understand the question like Why product design in such a way? or What was the problem that is the author trying to solve?. Kubernetes history begins before its conceptualization. Kubernetes is made for the container so we will have a quick tour of the container first.
Containers.
Well, who doesn’t love containers? I love the container(operating system virtualization) since have sawed the docker demo by docker creator Solomon Hykes during pycon in 2013. If you haven’t watched it is embedded for you. Go watch it as it just 5:21 min. It’s just awesome.
Although Linux container does exist before this but that is not the path we want to go now maybe some another time or you can go through my youtube.com playlist where I have covered this topic. Just remember that Linux container was way difficult to create and manage though there were few companies who are working with containers but all that is behind closed doors. Solomon brought Linux containers in the mainstream by making it so simple and releasing it to opensource.
It is not surprising that this demo created a new wave in the IT industry and every individual and organization is made aware of the power and feature provided by a container that causes widespread of the containers.
Docker was good to create and manage containers in one host but then people started to adopt the container and started to face issues such as managing multiple containers across the various host. At this moment we need some orchestration tool which will create and manage containers across various servers. Docker did try to solve this by creating a product called docker swarm but it was very early stage and didn’t much solve the problem as being a product.
Birth of Kubernetes.
Like I said earlier few companies were using the containers in their infrastructure. They have created complex software to create and manage containers. One of them was Google.
The big boys of Google who already solved this problem using their self-made container orchestration system called Borg which was they were using for a long time. The Googler Joe Beda, Brendan Burns, and Craig McLuckie decided to recreate their system from C++ to Go language and release to opensource. Kubernetes does not create or manage containers it uses docker for that. Kubernetes was made to handle the load scale of google so it has an edge over other orchestrator and it almost becomes de-facto standard for container management.
Google then work with Linux Foundation to create new organization who’s sole focus was to host and promote cloud-native product called Cloud Native Computing Foundation which now host 24+ project which include few popular such as Kubernetes, Prometheus, Containerd, Fluentd and envoy etc you can get full list at CNCF.org
Kubernetes is a very complex system but does the job which is why Kubernetes got wide adoption across the organization and many vendors started to provide the solution with Kubernetes. We have a very vibrant and healthy community around Kubernetes.
Introduction to Kubernetes.
Kubernetes had many name such as Seven of Nine before releasing with opensource in 1.0 in OSCON in 2015. Kubernetes is in Greek for “helmsman” or “pilot”. Kubernetes logo is for helm of ship. Because of such a long name(10 letter) many people prefer to called Kubernetes as K8S. which mean there are 8 letter in K and S.
Earlier Kubernetes version were focus on minimally viable orchestrator and it was build few binary and scripts but as product is matured we have well defined architecture and we have various service which have their own role. There is famous guild by Kelsey Hightower called kubernetes-the-hard-way which instruct creating an Kubernetes cluster by installing and configuring each and every component of Kubernetes.
Luckily we don’t have to do this anymore all components of Kubernetes are deployed as Kubernetes object in the container and there is various kubernetes deployment tool such as kubeadm, KOPS, and Kubespray etc available.
When we have new technology as exciting as Kubernetes we tend to misuse or misunderstand it. Below comic by Dilbert.com highlight same.
First of all, Kubernetes is not a product anymore. Kubernetes is a platform. We have the various module in the same. There were many operations in Kubernetes which could be a core component of Kubernetes but authors are chosen not to be. Kubernetes try to offload the non-core part by making use of the Plugin/Interface system because of this we have much cleaner and less complex(?) Kubernetes core. This plugin could be network, storage, or device etc we will cover this in detail later.
Imperative Vs declarative.
Kubernetes did a good job of managing containers across the various host. One of the main reasons is Kubernetes use declarative models instant of imperative one. In imperative, we pass exact instructions to software such as create the table in the database or script we use in an operating system. We pass a few commands and tell the software what to do and in which order we need to get the thing done. This has a few advantages when the system is static as we know the operating system state any point of time. But this is not true in a dynamic system where the state continuously changed such as kubernetes we can have a node crashed and a new node added we can have few containers crashed and not working in this situation we can not wait for the administrator acknowledge and make the correction.
Kubernetes does not take instructions such as create containers on the nodes with some configuration etc. Instant Kubernetes ask the user to define what is the desired stage and it does the job of finding the best way to make the current stage as the desired stage.
Kubernetes Reconciliation Loop.
Next big thing was self healing ability. Once the desired stage is achieved Kubernetes does not take just wait there. It then runs and loops to check if the current stage matches the desired stage and if not then again it will try to make the same. This loop run as an infinite loop called a Reconciliation loop. If we have any node or container crash in the future due to some issue then this loop with ensuring that we still have what we have requested. This is kind of self healing loop which is crucial is modern application.
For example, we have to specify that we want a total of 50 containers across the 10 nodes. This container may be for different applications and have a different requirement. We just specify the desired stage and then Kubernetes will schedule the container across the node. Let say in future if new of this container or node crash then this container will be re-spawned on the different node as long as we have enough capacity so don’t have to instruct the Kubernetes to move the container. This make Kubernetes powerful and easy to use. Kubernetes does not store state in itself it offload that to third party key-value store generally etcd by coreos.
lastly Kubernetes does not directly create container it use docker runtime for same. Also Kubernetes use various high level objects for it’s function such as Pod, Replica set, Deployment, service, ingress, secret and config maps etc. We will cover this object in details in details in upcoming topic.
In Next Topic we will see Architecture of Kubernetes and will go through various object it provide.
Hope you enjoyed the article.
If you like the story, please click the clap 👏 button a few times to show your support!
Part 2 -architecture is published at https://medium.com/@yogeshkunjir/kubernetes-for-human-part-2-architecture-11bffb01b1f0
