When you deploy Kubernetes, you get a cluster — a group of machines working together to run your containers. You do not manage individual servers anymore. You tell Kubernetes what you want and it figures out where and how to run it.

The Core Hierarchy

Kubernetes
    |
  Cluster       -> full setup, all servers grouped together
    |
  Node          -> one single server inside the cluster
    |
  Pod           -> smallest unit, runs inside a node
    |
  Container     -> your actual app, runs inside a pod

Every node in the cluster is either a Control Plane node (the brain) or a Worker node (where your apps actually run). Together they form the cluster.

Cluster
|
|-- Control Plane (Master)
|       |-- API Server
|       |-- etcd
|       |-- Scheduler
|       |-- Controller Manager
|
|-- Worker-node-1
|       |-- Kubelet
|       |-- Kube-Proxy
|       |-- Container Runtime
|       |-- [Pod] [Pod]
|
|-- Worker-node-2
|-- Kubelet
|-- Kube-Proxy
|-- Container Runtime
|-- [Pod]

Control Plane — The Brain

The Control Plane makes all the decisions. It watches the cluster, decides where to run Pods, and constantly checks that everything matches what you asked for. It does not run your application Pods — that is the Worker nodes' job.

API Server

The front door to Kubernetes. Every single request — whether from kubectl, from another component, or from an external tool — goes through the API Server first. Nothing bypasses it.

You run: kubectl apply -f deployment.yaml

  kubectl -> sends HTTPS request to API Server
  API Server: is this valid YAML?
  API Server: does this user have permission?
  API Server: stores desired state in etcd
  API Server: notifies Scheduler — "new pods need placing"

The API Server does not do the work itself. It validates, authenticates, stores state, and delegates to the right component.

Master Node Components

Master API server k through worker se communicate krta hai

image.png

The Master has 4 key components:

Component What it does
API Server The entry point — all commands go through here
Scheduler Assigns a Node to newly created Pods
ETCD A key-value store that holds all cluster data
Control Manager Responsible for managing the state of the cluster

etcd

A distributed key-value store that holds the entire state of the cluster. Everything Kubernetes knows lives here — which Pods are running, which nodes exist, what their IPs are, every ConfigMap, Secret, Deployment, and Service.

etcd stores:
  -> All nodes and their current status
  -> All Pods and which node they are on
  -> All Deployments, Services, ConfigMaps, Secrets
  -> The desired state AND the current observed state

If etcd is lost -> cluster loses all memory of what exists.
That is why etcd is always backed up in production.