Kubernetes Fundamental #0

Hello everyone! I guess this is the first time for Adaptive Network Lab launch the first article that use English as the article language. I hope you guys are enjoying it! If you don’t, just turn on translate mode of this article on your web browser. So today I’m going to show you some of the Kubernetes Fundamental that you need to know before you become a Kubernetes Administrator. This’ll show you some of the basic concept to the some advanced Kubernetes component architecture.

Now we’re going to know about three things. First we’ll learn cluster architecture, second knowing the basic of Master Node component and last knowing some of the component of Worker Node.

Okay let’s begin!

Cluster Architecture

Kubernetes will host your application in the form of container, also enable the communication between your different service within your application. There’s a bunch of Kubernetes component to make this possible.

There are two different node that at least require on Kubernetes cluster, which is master node and worker node. Each node has it’s own responsibilities for each little component that exist on that node. Basically master node is the one who manage, plan, schedule and monitor the entire workload happen, while worker nodes are they who host your application as a container.

Master Node Component

ETCD Cluster – Key Value Store

This component run as a database to store the information about a core thing in order to maintain the cluster.

• What is key-value store?

The data that store in key and value format.

It is use not to store an ordinary data like that but to store and retrieve the small chuck of data, like configuration data that just require fast read and write.

• What is the actual role in the cluster?

ETCD store the data regarding Nodes, PODs, Configs, Secrets, Accounts, Roles, Binding, etc. The information you get form the kubectl get are fetch from the ETCD server, and if there’s changes ETCD server always store that info and be updated every time.

Kube-API Server

The one who orchestrate all operation between component within the cluster, kubectl command will exposes the Kubernetes API to a certain components in order to do some management operation.

To make it easier, here’s the workflow of pod production process, so you can understand the role of it.

1. API Handler
   curl –X POST /api/v1/namespaces/default/pods ...[other]
2. Authenticate User
3. Validate Request
4. Retrieve Data
5. Kube-API Server
6. Update ETCD
7. Kube-API Server
8. Scheduler
   Realize that pod must be assign a pod to a right node.
9. Kube-API Server
10. Kubelet
    Create the pod on the node then assign container runtime to deploy the image.
11. Kube-API Server
12. Update ETCD

So All of the process between the component must be go through Kube-API Server.

Kube Controller Manager

In Controller Manager there are some different area that need to look at, like Node-controller to handling the broken node, onboarding new node to the cluster, then Replication-controller to ensure the certain number of replication are running in your replication group, and many more of controllers.

The concept behind the controller for every component here is that first they are continuously lookout status of it and second take some action to resolve some situation.

Kube Scheduler

Scheduler on a master node identifies the right node to place a pod based on some resource requirement, and many more, we’ll talk about this later on upcoming article.

Worker Node Component

Kubelet

The agent that runs on each worker node in a cluster listens to the instruction of kube-api-server and executes it within the own worker node. And it fetch the status of the pod and node to report it to the master node.

Kube Proxy

This service ensure that every pod on the node can communicate with each other, with the existence of necessary rules are in place on the worker node.

---

So to wrap this up, all of this component whether on worker or master node, exist in a form of pod. This pod is contain a container, so of course we need container runtime to make all this work, like Docker for instance.

Okay I think this all for this time. I’ll see you again in the next article to discuss pod, deployment, etc. So see you!

Thank you Kode Kloud for the material resources.