Understanding Kubernetes Architecture: A Beginner's Guide
Before this blog look into the Kubernetes Introduction
Kubernetes Architecture
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
when we deploy Kubernetes, we get a cluster. A Kubernetes cluster consists of a set of worker nodes which are also called nodes. The worker nodes host the Pods that are the components of the application. To manage these worker nodes and pods we have a control plane.
Control plane
The control plane components make the ultimate decision regarding the cluster scheduling pods, detecting pods and responding to cluster events. Control plane components can be run on any machine in the cluster. The control plane is a combination of components like an etcd, an API server, a Scheduler, and a Control Manager. The components of the Control plane are
Kube-API Server
One of the components of the control plane that exposes the Kubernetes API is the API server. Data for the API objects, which include pods, services, replication controllers, and others, are validated and configured by the K8s API server. Kube-apiserver scales horizontally which is it scales by deploying more instances.
etcd
Consistent and highly-available key value store as Kubernetes backing store for all cluster data. If the etcd backing store is used by your Kubernetes cluster, be sure to have a data backup strategy in place.
Kube-schedular
Component of the control plane that searches for freshly formed Pods that have not yet been given a node and chooses one for them to run on.
Individual and group resource needs, hardware/software/policy restrictions, affinity and anti-affinity standards, data locality, inter-workload interference, and deadlines are all taken into consideration while making scheduling decisions.
kube-controller-manager
component of the control plane that controls controller operations.
Although technically each controller should operate as a separate process, they are all compiled into a single binary and run in a single process to decrease complexity.
Several examples of these controllers include:
Node controller: In charge of identifying and reacting to node failures.
Job controller: Keeps an eye out for Job objects that stand for sporadic duties, then constructs Pods to carry out those tasks.
In order to connect Services and Pods, the EndpointSlice controller populates EndpointSlice objects.
Create default ServiceAccounts for new namespaces with the ServiceAccount controller.
Node components
Every node runs node components, which keep running pods running and provide the Kubernetes runtime environment.
Kubelet
an agent that is installed on each cluster node. It confirms that containers are operating within a Pod.
The kubelet checks that the containers described in a set of PodSpecs that are delivered via various mechanisms are active and in good condition. Containers that were not created by Kubernetes are not managed by the kubelet.
Kube-Proxy
Every node in your cluster runs kube-proxy, a network proxy that executes a portion of the Kubernetes Service concept.
On nodes, kube-proxy keeps track of network policies. These network rules permit network communication to your Pods from sessions both inside and outside of your cluster.
If an operating system packet filtering layer exists and is available, kube-proxy uses it. If not, kube-proxy automatically forwards the traffic.
Container runtime
The program in charge of executing containers is known as the container runtime.
Container runtimes like containerd, CRI-O, and any other CRI (Container Runtime Interface) implementation are supported by Kubernetes.