Kubernetes Cluster Architecture

etcd

Cluster State Storage: etcd stores the state of all Kubernetes objects, such as deployments, pods, services, config maps, and secrets.
Configuration Management: Changes to the cluster configuration are stored in etcd, allowing Kubernetes to manage and maintain the desired state of the cluster.
note: etcd could be in kube-system

Kube-api-server

The Kubernetes API server is the central component of the Kubernetes control plane that exposes the Kubernetes API and serves as the gateway for all interactions with the cluster.

The Kubernetes controller

The Kubernetes controller manager is a daemon that runs controllers, which are responsible for monitoring the state of the cluster and making or requesting changes to achieve the desired state. (reach to desired state via registered etcd variables)

Kubelet

The kubelet is the Kubernetes agent responsible for managing the pods on a node, reporting their status, and ensuring the desired state is achieved.

Kubeproxy

In simpler terms, the kube-proxy makes sure that network communication between different components of the Kubernetes cluster (pods, services, etc.) works as expected, by managing the necessary network configuration and rules on each node.

Service Networking: The kube-proxy ensures that all the network traffic intended for a Kubernetes Service can be correctly routed to the appropriate pods providing that service.
Load Balancing: The kube-proxy can perform basic load balancing across the pods that are part of a Service, distributing incoming traffic among them.
Network Proxy: The kube-proxy acts as a network proxy, forwarding traffic to the correct pod based on the Service configuration.
Network Rules: The kube-proxy is responsible for setting up the necessary iptables rules or other network rules on the node to achieve the desired network behavior.

CRI

By using the CRI, Kubernetes can maintain a consistent interface for container management, while allowing users to choose the container runtime that best fits their needs and infrastructure.
(there is options )

Scheduler

The Kubernetes scheduler is essential for ensuring that the cluster's resources are utilized efficiently and that pods are scheduled onto nodes that can handle their resource requirements and constraints.

workernodes or node1 & node2

In simple terms, the worker nodes are the "workhorses" of the Kubernetes cluster, where the actual application workloads are executed. They provide the computing resources (CPU, memory, storage) needed to run the containerized applications, while the Kubernetes control plane manages the overall orchestration and scheduling of these workloads across the cluster.

In simple terms, a Pod in Kubernetes is the smallest and most basic unit of computing that you can create and manage in the Kubernetes system.

Pod

A Pod is a group of one or more containers that are deployed together on the same host (worker node) and share the same resources, such as:

Interaction scenario :

1.Define the Application Configuration:
Create a YAML file describing a deployment for a simple web application.

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web-container
        image: nginx
        ports:
        - containerPort: 80

2.Apply the Configuration:
Use kubectl to create the deployment in the cluster.

kubectl apply -f my-deployment.yaml

Interaction:

• kubectl sends the configuration file to the Kubernetes API server.
• The API server validates the configuration and stores it in etcd, the cluster's key-value store.

3.API Server Processes the Request:

• The API server creates a new deployment object in etcd.
• The API server responds to kubectl with the status of the request.

4.Deployment Controller Actions:

• The Deployment controller, part of the controller manager, notices the new deployment object.
• It creates ReplicaSet objects to match the desired state specified in the deployment.

5.ReplicaSet Controller Actions:

• The ReplicaSet controller sees the new ReplicaSet and ensures that the correct number of pods are running.
• It creates new Pod objects in etcd to match the desired replicas.

6.Scheduler Actions:

The Scheduler detects new unscheduled pods and assigns them to appropriate nodes in the cluster.

7.Kubelet Actions:

• The kubelet on each assigned node sees the new Pod objects.
• It instructs the container runtime (like Docker or containerd) to pull the nginx image and start the containers.

8.Pods Running:

• The web application is now running on multiple nodes as specified.
• The kubelet continuously monitors the pods to ensure they remain in the desired stat