Here is a very comprehensive, detailed tutorial/guide explaining each Kubernetes cluster architecture component you’ve listed. This guide is suitable for learning, interviews, or team documentation, and each component is clearly explained with details on how it works, its purpose, and practical usage.

---

Kubernetes Cluster Architecture: Complete Guide

---

1. Overview of Kubernetes Cluster Architecture

A Kubernetes (K8s) cluster consists of several components working together to manage, orchestrate, and scale containerized applications. The architecture is designed to be modular, highly available, and scalable. The main building blocks are:

Workstation → Master Node(s) → Worker Node(s)

---

2. Workstation

This is the user’s machine or environment used to manage and interact with the Kubernetes cluster. Most operational tasks, cluster management, and resource definitions start here.

Key Tools on Workstation

a. kubectl

• Description:
  kubectl is the command-line tool for interacting with the Kubernetes API server. It allows you to deploy applications, inspect and manage cluster resources, and view logs.
• Common Commands:
  • kubectl get pods
  • kubectl apply -f deployment.yaml
  • kubectl logs <pod-name>
• How it works:
  Communicates with the Kubernetes API server over HTTPS, using kubeconfig for authentication and cluster context.
• Practical Example: kubectl get nodes kubectl describe service my-service

b. YAML

• Description:
  YAML files are used to define the desired state of Kubernetes resources (Pods, Deployments, Services, etc.) in a declarative way.
• How it works:
  You write a resource definition in a .yaml file and use kubectl apply -f file.yaml to create or update resources.
• Example YAML:
• apiVersion: v1 kind: Pod metadata: name: nginx-pod spec: containers: - name: nginx image: nginx:latest

---

3. Master Node

The Master Node is the brain of the Kubernetes cluster. It manages the cluster state, schedules workloads, and handles API requests. In production, you typically have more than one master for high availability.

Core Components on Master Node

a. API Server

• What it is:
  The API Server is the central management point for the Kubernetes cluster. It exposes the Kubernetes API, which is a RESTful interface used by all other components and by kubectl.
• How it works:
  • Receives requests (create, update, delete, get) from users and other components.
  • Validates and processes API calls.
  • Stores the resulting state in etcd.
• Deployed as:
  Runs as a Pod on the master node (using an image from the Google Registry).
• Practical Notes:
  • All communication in the cluster passes through the API Server.
  • Secures communication via SSL/TLS and authenticates users.
  • Example command to access: kubectl get nodes (This command communicates with the API server.)

b. etcd

• What it is:
  A distributed key-value store that holds the entire configuration and state of the cluster.
• How it works:
  • The “single source of truth” for the cluster’s desired and actual state.
  • Stores objects like pods, deployments, configmaps, secrets, etc.
  • Highly available in production with a cluster of etcd nodes.
• Deployed as:
  Runs as a Pod on the master node (using an image from the Google Registry).
• Backup:
  Essential to regularly back up etcd for disaster recovery.

c. Controller Manager

• What it is:
  The brains behind state management in Kubernetes. Runs controllers that ensure the cluster is always at the desired state.
• How it works:
  • Watches etcd and the API Server for changes.
  • Runs controllers such as:
    • Replication Controller (ensures correct number of pods)
    • Node Controller (tracks node health)
    • Endpoint Controller (populates endpoints for services)
  • Takes action if the current state diverges from the desired state (e.g., creates new pods if one crashes).
• Deployed as:
  Runs as a Pod on the master node.

d. Scheduler

• What it is:
  Decides which worker node will run a new pod based on resource requirements and policies.
• How it works:
  • Watches for newly created pods that don’t have a node assigned.
  • Selects an appropriate node based on available CPU/memory, taints/tolerations, affinity/anti-affinity, etc.
  • Updates the pod spec to bind it to the selected node.
• Deployed as:
  Runs as a Pod on the master node.

e. kube-proxy

• What it is:
  Handles network proxying and load balancing for services in Kubernetes.
• How it works:
  • Runs on every node (both master and worker nodes).
  • Maintains network rules and manages traffic routing to pods.
  • Enables access to Kubernetes services via ClusterIP, NodePort, or LoadBalancer.
• Deployed as:
  Runs as a Pod on both master and worker nodes.

---

Supporting Tools on Master Node

• kubelet:
  Node agent that ensures containers are running as specified in PodSpecs. (More on this in Worker Node section.)
• Docker/ContainerD:
  Container runtimes that pull container images and run containers. Kubernetes supports both; ContainerD is becoming the standard.
• kubectl:
  Used on master for troubleshooting and cluster management.
• kubeadm:
  Tool for bootstrapping and managing Kubernetes clusters.
  • kubeadm init is used to initialize a new master node.

---

Master Node Setup Example

sudo kubeadm init --pod-network-cidr=10.244.0.0/16
# Follow the output instructions to set up kubectl config and join worker nodes.
Code language: PHP (php)

---

4. Worker Node

The Worker Node is where application workloads run. These nodes are registered with the cluster and managed by the control plane (masters).

Key Components on Worker Node

a. kubelet

• What it is:
  The node agent. Ensures that the containers described in PodSpecs are running and healthy.
• How it works:
  • Communicates with the API Server to receive pod specs.
  • Starts/stops containers as needed.
  • Reports node and pod status back to the master.

b. kube-proxy

• What it is:
  As described above, enables network communication and load balancing for services on each node.

c. Container Runtime (Docker/ContainerD)

• What it is:
  The engine responsible for running containers.
• How it works:
  • Pulls images from container registries (e.g., Google Registry, Docker Hub).
  • Starts, stops, and manages the lifecycle of containers.

d. kubectl

• Optional on worker:
  Can be used for troubleshooting but not required for basic node function.

e. kubeadm

• How it’s used:
  • Used to join the worker node to the cluster: sudo kubeadm join <master-ip>:<port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>

---

Worker Node Setup Example

# Install kubeadm, kubelet, containerd/docker
# Join cluster (command given by kubeadm init on master)
sudo kubeadm join <MASTER_IP>:6443 --token <TOKEN> --discovery-token-ca-cert-hash sha256:<HASH>
Code language: HTML, XML (xml)

---

5. Summary Table: Components and Their Functions

Component	Runs On	Description / Purpose
kubectl	Workstation	CLI tool to manage cluster and resources
YAML	Workstation	Declarative configuration files
API Server	Master Node	Cluster gateway, exposes Kubernetes API
etcd	Master Node	Distributed key-value store for cluster state
Controller Manager	Master Node	Maintains desired state via controllers
Scheduler	Master Node	Assigns pods to worker nodes
kube-proxy	Both	Manages networking, service load balancing
kubelet	Both	Ensures container health and execution
Docker/ContainerD	Both	Container runtime to run pods
kubeadm	Both	Bootstrap and manage cluster

---

6. How Everything Works Together: Flow Example

1. User writes a YAML manifest on the workstation.
2. User applies manifest with kubectl apply -f file.yaml.
3. kubectl sends the request to the API Server.
4. API Server stores configuration/state in etcd.
5. Controller Manager notices a new deployment is needed.
6. Scheduler assigns pods to available worker nodes.
7. kubelet on worker nodes creates and manages containers via Docker/ContainerD.
8. kube-proxy sets up networking rules so services are reachable.

---

7. Conclusion & Best Practices

• Separate control plane and worker responsibilities for security and reliability.
• Always secure etcd and take regular backups.
• Use declarative YAML for consistent, version-controlled cluster management.
• Leverage kubeadm for standard, reliable cluster bootstrapping.
• Use kubectl with RBAC (Role-Based Access Control) to restrict access.
• Regularly update cluster components for security and features.

---