Kubernetes cluster consists of various components. Let's understand each.
Control Plane Components
Kube-apiserver: Only interface that exposes a RESTful API that can be used to create, update, and delete resources in the cluster.
- Responsible for authenticating, authorizing and validating the requests.
Kube-scheduler: Responsible for scheduling containers onto nodes in the cluster.
When scheduling Pods scheduler takes into account factors such as resource availability, node health, and Pod affinity and anti-affinity rules.
Scheduler does the node selection in 2 steps-
Filtering
Scoring
Kube-controller manager: The controller manager is the intelligence behind the Kubernetes.
Each controller is a single and separate process
Controllers are the control loops that are responsible for managing the lifecycle of Pods, Services, and other resources in the cluster.
Kube-controller manager consists of a variety of controllers that ensures that Pods are running on nodes, that Services are available, and that resources are used efficiently, etc.
Node controller: Responsible for managing the nodes.
Pod controller: Responsible for managing the pods.
Service controller: Responsible for managing the services.
Replication controller: Ensures that the desired number of replicas for each pod is running
Deployment Controller: Uses the replication controller and is responsible for running the pods
DaemonSet controller: Responsible for managing the daemonsets.
Job controller: Responsible for managing the jobs.
ServiceAccount controller: Create default ServiceAccounts for new namespaces.
Etcd: Etcd is a distributed key-value datastore that is used to store cluster state such as the nodes, Pods, Configs, Secrets, Service Accounts, Roles, Bindings, etc
Worker Node Components
Kubelet: An agent that runs on each node in the cluster and ensures that containers are running in a pod.
Container Runtime Interface(CRI): Responsible for running containers. Kubernetes supports container runtimes such as containerd, CRI-O, cri-dockerd and other Kubernetes compliant CRI.
Kube-Proxy: Runs on each node and maintains the network routes. When new services are created, it creates appropriate rules(iptable route) to forward traffic to the backend pods.
Let's understand, how the request flows in Kubernetes cluster ?
- Let’s assume the USER made a request either through the kubectl tool or through rest api.
cli → kubectl get pods
api call → GET /api/v1/namespaces/default/pods
Since the Kube-apiserver is the only externally facing interface, the request is sent to it first, where it is authenticated, authorized, and validated.
After the request has been verified,
If the user requests information about resources then the Kube-apiserver sends the request to the ETCD datastore. Once the results are received, the Kube-apiserver updates the user with the results.
If the user requests to create, the Kube-apiserver creates a pod object and updates the ETCD datastore with that information. Additionally, inform the user about the pod.
The Kube-scheduler constantly checks for any resources that don't have a node assigned. Once located, the node selection process is used to determine, based on the requirements, which node is best suited for the pod. The Kube-scheduler updates the Kube-apiserver about the chosen node.
After that, Kube-apiserver sends a request to the Kubelet of the relevant worker node along with the PodSpec that should be executed.
Kubelet is a node agent that directs Container Runtime Engine(in this case Docker) to create and run Pod.
After completion, Kubelet updates Kube-apiserver with information about the created pod, and kube-apiserver updates the data in the ETCD datastore.
I hope you found this blog post helpful😀.
If you'd like to stay up-to-date🚀 with our content, please subscribe🤝 to our blog. You can also help us reach a wider audience by sharing this post.
Thank you for your support!🙏