Continuous Learning of Kubernetes

In 2026, Kubernetes still going strong with many companies using it and AWS keeps on maintaining its EKS product non stop. Back in the year 2016, 2019 and 2020, I was writing on Docker and Kubernetes and today in 2026, Kubernetes is still heavily in used. I thought about making some write-ups to explain some concepts that can be very helpful in Kubernetes. I will called this article Continuous Learning of Kubernetes - Part1. With the new tool I introduced in my blog "AI Rewrite, I see no reason why AI would not want to improve my article and keep the momentum.

Below are some links about Docker and Kubernetes articles I wrote in the past.

Understanding some basic concepts

Control Plane and Nodes

In Kubernetes there is the concept of Control Plane (Master / Manager) and Nodes (Slaves / workers); meaning there can be one or more as the Control Plane and others as Nodes.

API Server, Kubelet, Scheduler, Kube-Controller Manager, Kube-Proxy, kubeadm and ETCD

The main component of the Control Plane is the API Server. Workers and Control have Kubelet configured on the Nodes.

One of the Kubelet role is to report to the APIserver the resource and health of the node to the API Server. By default it report every 10 seconds.

The ETCD is a datastore (key value datastore) or the memory of the Kubernetes cluster.

Scheduler is another component that talk to the API. Scheduler role is to execute job where specific resource or pod need to be deployed.

Kube-controller manager, run all controllers in Kubernetes. Example are Replicaset Controller, Node Controller, Deployment Controller, etc. The Controllers role is to make sure the desired state is achieved. It will watch, compare and act.

KubeProxy runs on the control plane and nodes, It enable container to container communication. it enable the routing by enabling Service networking.

Kubeadm is the tool that works at the cluster level. It use to bootstrap the cluster, create certificates, authentication and control plane communication.

Another tool which is kubectl can be configured from outside the cluster/network is used to talk to the APIServer too.

Creating of a POD

Say for example you are creating a pod by doing a kubectl apply -f pod.yaml, the logic that follows to the creation of the pod is:

The request goes to the API Server.
When the API server received the request, and after authentication it will add a record in the database (ETCD).
API server will then talk to the scheduler about the request coming in.
The scheduler is there to find where that pod need to be deployed based upon the availability of the node and resources.
Once scheduler made a decision, the request goes to the API Server.
API server will now talk to the kubelet of the node concerned to execute the request.
The kubelet is not responsible with the request and that request will be used in a Container Runtime Interface (CRI).
The CRI (Example of CRI are CRI-O and Containerd) will get the image and create the container which sits inside the pod.
The network is managed by the CNI (Container Network Interface) (Example are Calico, Flannel, Cilium etc.) which means that the IP is managed by the CNI app.
The CSI (Container Storage Interface) (Example: EBS, Ceph) will attached the storage in case it was defined in the pod.yaml.
The kubelet will in turn reports to the API Server which in turn will be written to the ETCD.

In the next article I will make a list of some interesting commands. Kubernetes has been around since long and I think it's keeping the pace with technology and many developers still maintaining it. No wonder, AWS EKS still going strong.