Kubernetes Architecture
Best way to start learning Kubernetes is to understand it's basic architecture. Let's dive into the architecture of Kubernetes. Enjoy Happy Learning!
What is Cluster?
A cluster is a grouping of nodes that run containerized apps in an efficient, automated, distributed, and scalable manner. Kubernetes clusters allow engineers to orchestrate and monitor containers across multiple physical, virtual, and cloud servers.
Kubernetes Cluster
The Kubernetes cluster is made up of multiple nodes which can be virtual machines or physical servers depending on the cluster, these nodes run the containerized applications.
Nodes when work/run together form a cluster, Kubernetes clusters are comprised of master nodes and several worker nodes. The master node is also called the Control plane.
Pods are the smallest, most basic deployable objects in Kubernetes. A Pod represents a single instance of a running process in your cluster. Pods contain one or more containers, such as Docker containers.
Master Node/Control Plane
The role control plane is to run/control, which container will run different nodes.
It makes decisions about the cluster and pushes it toward the desired state.
Master Node also monitors the health of worker nodes and checks whether all the other components are working or not. It can also assign a healthy worker node if any of the nodes die.
It communicates between different worker nodes and ensures they are running.
Master Node/Control Plane Components
The Main components of the Master Node/Control Plane :
API Server / Kube-Apiserver
Kube-Scheduler
Kube-Control Manager
etcd
Cloud-Control-Manager
👑
API Server / Kube-apiserver
The user interacts with the master node using the API server or kube-apiserver whenever he wants to deploy its application.
It also acts as a gatekeeper that acts as an authenticator that authenticates that, only authorized requests to get through the cluster.
Kubernetes API server validates and configures data for the API objects which include pods, services, replication controllers, and others.
The master node tracks the state of all cluster components and manages the interaction between them using the API server.
Developers use Kubectl (CLI for Kubernetes) to communicate with the API server in the master node.
It consumes YMAL/JASON files.
API servers have three core functions:
API management
Request processing
Internal control loops
Kube-scheduler
When a user requests to start a new pod API Server validates the requests and then the scheduler identifies and decides where to place the pod.
It looks at the request made by the user and checks for the requirements it asks, then it searches for the worker nodes like which node is least busy or the node which can handle the particular request then it will schedule the new pod at that worker node.
Kubelet gets the requests from the schedular and executes the requests in that node.
Kube-control manager
It detects state changes in the cluster.
When pods die in any node it detects the state changes like the crashing of pods and tries to recover the cluster state as soon as possible to do so it requests the scheduler to reschedule those dead pods and in the same cycle, the scheduler decides based on the resource calculation which worker node should be assigned to restart those pods and requests the corresponding kubelets on those worker nodes to restart the pods.
etcd
Kubernetes uses etcd to store all its data like its configuration data, its state, and its metadata. It contains the configuration of containers.
etcd is also called cluster brain because it contains all the data on which the scheduler, control manager etc works. Example- etcd contains data to schedule the pods that the schedular uses to do its action.
etcd stores and replicates all Kubernetes cluster states.
It does NOT contain any application data.
Also, cluster changes get stored in a key value store of etcd.
Cloud-controller-manager
The cloud controller manager lets you link your cluster to your cloud provider's API, and separates the components that interact with that cloud platform from components that only interact with your cluster.
Cloud Manager components will talk to the cloud, and different cloud providers and it will ask them to provide a monitored disk or load balancer or any necessary service.
Worker Node Components
Each node will have multiple application pods with containers running on it the three main components of worker nodes that must be installed on every worker node so that cluster works properly :
Container Runtime
Kubelet
Kube-Proxy
Worker Node
Container Runtime
Container Runtime is responsible to run containers. The first process that needs to run on the worker node is container runtime, it can be docker or some other tech.
Kubelet
Kubelet gets the requests issued by the scheduler and the control manager, it reads the command and then starts the container inside the node. Kubelet is the process of Kubernetes and has the interface itself.
It interacts with the container-run time and the node, kubelet starts the pod with a container inside and then assign’s resources from that node to the container like CPU, RAM and storage resources.
It sees the available CPU and memory and then it deploys the container depending on those factors.
The communication between the nodes is done through services.
\Load balancer* when users want to access a container instead of directly accessing containers they will go through the load balancer because we will have multiple instances of the application. The load balancer might not be part of our cluster but it could be provisioned by our cluster.
\DSC* (Desired State Configuration) when any node crashes then k8s uses DSC and it raises desired state that the developer wants, if he wants to use 5 containers then at instances K8s should be running 5 containers and one of those go down/crashes then k8s will try to reschedule the crashed container inside the other node. This way K8s make sure that all the containers are up and running.
Kube-Proxy
Kube-Proxy forwards the request. It is the main networking component of our cluster, it runs on each node. It maintains the network rules on each node.
Kube-proxy creates iptables rules for Kubernetes services which ensure that the request to the service gets routed (and load balanced) to the appropriate pods,
(kubelet now no longer ever uses any iptables rules for its purposes; the things that it used to use iptables for are now always the responsibility of the container runtime or the network plugin, and there is no reason for kubelet to be creating any iptables rules.)
Basic Kubernetes Cluster
Kubernetes Cluster
Extra Points
Master Nodes require fewer resources compared to worker nodes.
When the complexity and demand of resources increase we can add more master nodes and node servers to our cluster to make it more powerful and meet our application requirements.
