Architecture:

Video reference: https://youtube.com/watch?v=NYsEPjk4SsU&si=kHo-iindAyVP3yNA

1. Cluster

Analogy: A cluster is like a whole organization where multiple teams work together.
Explanation: A Kubernetes cluster is the fundamental unit, made up of a Control Plane (the "brains") and Nodes (the "workers"). The cluster organizes everything and is where all Kubernetes tasks happen.

2. Control Plane(Master Node):

Analogy: Imagine this as the management team that decides what needs to be done and assigns tasks.
Components:
- API Server
  - Role: The API Server is like Kubernetes’ main entry point. Think of it as the front desk at a hotel. It receives requests for all the tasks, like creating or scaling applications, and manages authentication.
  - How It Works: Users interact with Kubernetes through the API server, whether to deploy new applications or make changes to existing ones. The API Server then interacts with other components to fulfill these requests.
- etcd (State Store)
  - Role: etcd is a distributed key-value store that holds the current and desired state of the entire Kubernetes cluster. It’s the “memory” of the cluster, keeping track of configuration data and the status of all components.
  - How It Works: Whenever a user requests a change, the API Server records it in etcd, which then becomes the source of truth for the cluster’s desired state. If a change is needed, etcd notifies other components to reconcile the current state with the desired state.
- Scheduler
  - Role: The Scheduler is the “matchmaker” that assigns workloads (Pods) to nodes based on resource availability and constraints.
  - How It Works: The Scheduler finds the best node for a new Pod, considering things like available memory, CPU, and specific node requirements. It ensures the workloads are efficiently distributed across the cluster.
- Controller Manager
  - Role: This component oversees the overall health of the cluster. It continuously checks that the actual state of resources matches the desired state and takes action if there’s a discrepancy.
  - How It Works: For instance, if a Pod crashes, the Controller Manager notices the change and launches a replacement to meet the desired state.

3. Worker Nodes

Analogy: Each Node is like an individual team member that works on tasks assigned by the Control Plane.
Explanation: Nodes are the physical or virtual machines that actually run the containerized applications. Each Node has:
- Kubelet: Monitors the state of each node and manages Pods. Basically runs the pods.
- Kube-Proxy: Manages network traffic, acting like an internal messenger, ensuring that requests reach the correct container.
- Container Runtime: Runs and manages the containers (e.g., Docker). It’s what actually starts, stops, and organizes containers on the Node.
  
  How It Works: The worker nodes receive instructions to run specific Pods and ensure they keep running smoothly. The Kubelet and Kube-proxy work together to handle communication and resource allocation.

How Data Flows Through the Kubernetes Architecture

To understand the flow of data in Kubernetes, let’s walk through each key component and describe its role in managing and orchestrating applications. Here’s a simplified flow to help visualize how data moves from the initial deployment request to the actual running containers in the cluster:

1. Client Request to API Server (User Interaction)

The process starts with an API request made by the user (or DevOps tool) via the Kubernetes CLI (kubectl) or any other API client to deploy an application or make changes to the existing setup.
Example: When a user requests the deployment of an application, this request is processed by the API Server, which serves as the main interface for all Kubernetes operations.

2. API Server (Control Plane)

The API Server receives the request and acts as the gateway for all control plane communications. It’s responsible for validating and authenticating requests.
Once validated, the API server writes the desired state of the cluster (such as deploying a new Pod or updating a configuration) to etcd, Kubernetes’s backing store.
Data Flow Example: When a deployment request is made, the API Server registers the request and logs it in etcd as the new desired state.

3. etcd (State Store)

etcd stores all cluster data and state, essentially acting as Kubernetes’s "memory." It ensures high availability and data consistency across the entire cluster.
After the API server logs the new state, etcd maintains this information and makes it accessible to the rest of the control plane.
Data Flow Example: The desired state for a new Pod deployment is stored in etcd, so that Kubernetes knows this state should be maintained and reconciled if it changes.

4. Scheduler (Pod Assignment)

The Scheduler watches for unassigned Pods in etcd and assigns them to specific nodes based on factors like resource requirements and node capacity.
The scheduler makes these assignments and updates the Pod information with the specific node details in etcd.
Data Flow Example: If a new Pod is requested, the Scheduler determines the best-suited node and assigns the Pod to it.

5. Controller Manager (State Reconciliation)

The Controller Manager monitors the state in etcd, comparing the desired state (what is defined by users) with the actual state of resources.
If the actual state deviates from the desired state (e.g., a Pod crashes), the Controller Manager takes action to bring them back into alignment by, for instance, restarting the Pod.
Data Flow Example: If a Pod goes down, the Controller Manager detects this deviation and issues a command to create a new Pod, updating etcd with the correct state.

6. Worker Nodes (Executing the Workload)

Once assigned, the Pod is created on the Worker Node. Each node runs several components that enable it to communicate with the control plane and run application workloads.
Kubelet: This agent communicates with the API Server, ensuring that containers described in Pods are running correctly. It watches for new assignments from the Scheduler and interacts with the container runtime (like Docker) to start containers.
Kube-proxy: Handles networking for the node, managing rules to expose and route traffic between Pods and services.
Container Runtime: Manages and runs containers within the Pods, allowing the application to operate as expected.
Data Flow Example: After a Pod is scheduled to a node, the Kubelet interacts with the container runtime to pull the necessary images and start containers. Networking rules are then set up by Kube-proxy to make the container accessible.

7. Pod & Service Communication

Pods run the application’s containers, while Services manage communication and networking. Services are stable, fixed access points that allow clients or other applications to connect to Pods.
Data Flow Example: Once the containers are running, a Service can expose them to the network. If external access is required, an Ingress can route external traffic to the Service, which then directs it to the Pods.

8. Persistent Storage (If Needed)

If a Pod requires data persistence (to survive restarts), it uses Persistent Volumes and Persistent Volume Claims to request and mount storage.
Persistent storage allows Pods to maintain data independently of their lifecycle, ensuring it’s preserved even if a Pod is rescheduled on a different node.
Data Flow Example: A Pod that manages a database could use Persistent Volumes to ensure that database data isn’t lost if the Pod is restarted.

Summary of Data Flow

User request → API Server
API Server updates desired state → etcd
Scheduler assigns Pods → Worker Nodes
Kubelet starts containers on nodes → Containers run in Pods
Kube-proxy handles networking → Service & Ingress route traffic to Pods
Persistent Volumes (if required) are attached to retain data

Each of these steps ensures Kubernetes can maintain a desired state, dynamically adapt to changes, and provide fault-tolerant, scalable application hosting.