Hi, This is part of the series although this is an independent topic you can check out my previous post. https://medium.com/@yogeshkunjir/kubernetes-for-humans-part-1-history-c8090ca0fe92 to get in sync.
I have seen a lot of people from different backgrounds try to understand Kubernetes and then they see how complex it is and kind of give up. First, we try to tackle that and then we see in general architecture/component of Kubernetes. Kubernetes is complex software so it is best if we compare this with something we are familiar to give us a perceptive which is the car.
So we are going to learn about the car first is what is your aim. It may happen you might not able to get one or two thing but don’t give up continue reading till end you will still have better understanding of things.
As we all aware of the learning car will be have following learning path.
- To learn to drive the car.
- To sell/promote the car.
- To repair/manage own car.
- To manufacture a car.
If I take above path and loosely convert it to Kubernetes it will be as below
- Developer who want to learn Kubernetes
- The consultant who want to deploy Kubernetes
- Dev-ops or SRE who manage Kubernetes
- And finally the authors of Kubernetes.
If you go from top to bottom the difficulty will increase and no matter under what category you are you have to go from top to down. you can’t manage the car if you don’t know how to drive it. So let’s start with learning to drive the car.
Car is a complex to build and operate but the car is not a whole object it is made up of various components that are assembled. Such as an engine, body, wheel, and gearbox, etc. Each has its independence function and each one has a crucial role in car function.
Similarly, Kubernetes have a lot of component some of them are shipped with core and sometime they are supply as add-on and few are third party. To keep it simple we will start with core component for now.
Many times when we want to carry heavy luggage we have a trailer attached to the car. In this case, The car is an important factor still we required a few things in the attached trailer such as wheels and tow hitch etc.
Similarly, We have multiple sometimes few hundred nodes or servers in the Kubernetes cluster and to run load we have few nodes as master and rest node are called as a just node. (earlier it was called as a minion which I liked). Both Master and node will have Kubernetes component running but they will be different. Because of this we have 2 type of Kubernetes components.
- Kube control plane. (Run on master)
- Node control plane.
Master node as name suggest they are responsible for entire Kubernetes cluster so they will host all critical component of Kubernetes such as.
- Kube API server
- ETCD
- Kube Controller manager
- Kube Scheduler
- Cloud Controller manager
- Kubectl
And Node control plan have
- Kubelet
2. Kube-proxy
3. Container Runtime
I know this are many components but car also have a lot component. It is good that kubernetes author has divided this big software in smaller components which have their well defined function. We will go through each one in short now and may be in deep in future as we go in details.
Below in architecture diagram present in official document.
Kube control plane or Master node.
Let start with car then trailer will be easy to understand so will go through all master components first.
Kube API server
This is kinda heart of Kubernetes. We can create different objects in Kubernetes we call them API objects. They are such as pods, services, replication-controllers, secret and ingress, etc. We will go each on in detail in an upcoming topic for now just assume them as workload. When we want to create something we create this API object to access the actual object, Example, If I want to create a container then we have to create an API object called pod which will create the container for us on one of the nodes the configuration of container is provided in API object.
But how we can interact with Kubernetes to make this object. Well, the Kube API server helps us. It is a server which hosts and REST endpoint where we can send create an update of delete these objects we just make a REST call to Kube API server with proper Authorization. Kubernetes API server validates and verifies the request and create the requested object in database.
We don’t have to create every request as REST call we have various clients which do that for us. The official is kubectl when we type any command in kubectl it translates our request as API call to Kube API server.
One thing to note that not only our request all requests even by other kubernetes components should go through this API server. It makes architecture cleaner but then it might become a single point of failure but no worry this server is stateless and we can have multiple API servers in the environment which is also recommended in a production-like environment.
Remember Kube API server does not create an actual object it just write it down in database. Then who create it? will come to that in later.
ETCD
If the Kube API server is the heart then etcd is the brain of Kubernetes but hay we are talking about the car then it will be chassis of car it holds everything.
etcd is not created by Kubernetes authors. etcd is a distributed key-value store created by a company called coreos which then acquired by Redhat which then acquired by IBM. When Kubernetes authors wanted to store the data they want something simple but highly resistant which is exactly what etcd is.
etcd is a database but it stores only key value. It is distributed mean we can have multiple etcd servers running at the same time. This helps a lot in a case like Kubernetes. In kubernetes, we discussed that the Kube API server is stateless because it stores the entire state in etcd. All objects created in kubernetes along with configuration are stored in etcd.
Kube Controller manager
Remember the reconciliation loop we talk about it actually present in the API server itself. all it does is match the current state of the cluster with the desired state as per configuration present in etcd. Actually, we have multiple controller running which tracks the state of each object and makes it state as the desired one. In the car team, we can say it is an autopilot that will take necessary action on our behalf.
So if we have one node down which terminate few container replicas this will get in action to create the same container on a different node.
Kube Scheduler
So we till now we have a user who makes a request to Kube API server which then writes down in etcd. We have a Kube scheduler that is responsible to create the object on the actual node. Kube scheduler decides on which node newly requested pod should run.
Kube scheduler will see at the specification of the container and it knows the remaining capacity of all node so it will filter the available node to find an eligible node. If we have more eligible node It also gives a score to the node and then the pod is assigned to the best possible node.
Cloud Controller manager
Being a CNCF(cloud-native Computing Foundation) project the primary location to run Kubernetes is on the cloud. To make use of most cloud offering Kubernetes has a Cloud controller manager. This is kind of entertainment system in car you can skip it but it is best to have in car for smother experience.
It can provide multiple benefits such as check the node. create a new node or create and manage the Load balancer or security group and server behind load balancer etc.
You can run Kubernetes on own premises then we don’t require this component.
Kubectl
We have covered kubectl in Kube API server this is kind of driving assembly in car. No matter what is your aim to learn Kubernetes you have to learn kubectl command.
Well we have done with all major component, Just hang in there till we do the node component.
Node control plane.
Node component run on each and every node. They take order from Kubernetes manager and then revert with the task details.
Kubelet
This is an important component of any node. It will be in contact with the master node once any scheduler requests container creation it requests to Kubelet to do the same. Kubelet then take all required specification and pass this to container run time to create the container. Once the container started it will contentiously monitor the container and report it’s status to the master node.
In our car term it may be tow hitch
Kube Proxy
Kube proxy is responsible to create network rules on the host. In Kubernetes, we have a service concept that is closely related to load balancer Kube proxy help to implement it.
Kube Proxy will use IPVS and iptables to configure rule in host machine. In our car term it will be whels of our trailer.
There is another network components call CNI or overlay network we will discuss that in later series as it is not core component. For time being remember that kube proxy and overlay network are different.
Container Runtime
Though container runtime is not provide by Kubernetes it is the core component of kubernetes. This is the one who responsible for creating and destroy container on host system. Kubernetes author don’t want to be this part of their system inorder to provide plug and play approach. You can choose any container runtime such as docker or cri-o etc as long as it follow OCI(open container initiative) specifications.
This is actual workforce which carry load. Storage space in trailer can be compared to this. We can put all the load in that space.
And that’s all. In next chapter we will discuss all important API object provide by Kubernetes.
Hope you enjoyed the artical.
If you like the story, please click the clap 👏 button a few times to show your support!
