Kubernetes کے فنِ تعمیر کو بیان کریں: control plane بمقابلہ worker nodes اور ان کے اجزا۔

Question

IT Interview Practice · Accepted Answer

ایک Kubernetes cluster میں دو قسم کی مشینیں ہوتی ہیں: **control plane** (وہ "دماغ" جو فیصلے کرتا اور حالت محفوظ کرتا ہے) اور **worker nodes** (جہاں آپ کے Pods حقیقتاً چلتے ہیں)۔ ہر ایک کے پاس اچھی طرح متعین اجزا کا ایک چھوٹا مجموعہ ہوتا ہے۔

## بڑی تصویر

```text
┌──────────────── CONTROL PLANE (the brain) ────────────────┐
│                                                            │
│   kube-apiserver ── the front door; ALL comms go through it│
│        │                                                   │
│   etcd ───────── key-value store: the cluster's SOURCE OF  │
│                  TRUTH (all objects & desired state)       │
│   kube-scheduler ── decides WHICH node a new Pod runs on   │
│   controller-manager ── runs control loops (reconcilers)   │
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (your apps) │ │  └ Pods (your apps) │
└─────────────────────┘ └─────────────────────┘
```

## Control plane کے اجزا

```text
kube-apiserver        The single entry point. Exposes the REST API; validates &
                      persists objects to etcd. kubectl, controllers, and kubelets
                      all talk ONLY to the apiserver.
etcd                  Distributed, consistent key-value store. Holds the ENTIRE
                      cluster state (desired + current). Lose etcd = lose the cluster.
kube-scheduler        Watches for Pods with no node assigned and picks the best node
                      (based on resource requests, affinity, taints, etc.).
kube-controller-      Runs the control loops: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, etc. Each loop drives actual → desired.
cloud-controller-     (On cloud) integrates with the provider: load balancers, routes,
manager               node lifecycle.
```

## Worker node کے اجزا

```text
kubelet          The node agent. Talks to the apiserver, starts/stops containers via
                 the runtime, and reports Pod & node status. It makes the node's
                 reality match the Pods assigned to it.
kube-proxy       Programs the node's networking (iptables/IPVS) so that Service virtual
                 IPs are load-balanced to the right Pod endpoints.
container runtime The software that actually runs containers (containerd, CRI-O).
```

## ایک "kubectl apply" نظام میں کیسے بہتا ہے

```text
1. kubectl → kube-apiserver: "I want a Deployment with 3 replicas"
2. apiserver validates & writes the object to etcd
3. controller-manager (deployment→replicaset controller) sees it, creates 3 Pod objects
4. scheduler sees 3 unassigned Pods, assigns each to a node (writes back via apiserver)
5. each node's kubelet sees its Pods, tells the runtime to pull images & start containers
6. kube-proxy wires up Service networking so traffic reaches the new Pods
Everything is a WATCH + RECONCILE loop mediated by the apiserver.
```

```bash
kubectl get nodes                 # nodes کی فہرست (control-plane + workers)
kubectl get pods -n kube-system   # control-plane / system اجزا دیکھیں
kubectl get componentstatuses     # مرکزی control-plane حصوں کی صحت
```

## یہ کیوں اہم ہے

control plane اور worker nodes کے درمیان تقسیم کو — اور ہر جزو کے کردار کو — سمجھنا ہی وہ چیز ہے جو Kubernetes کو ایک black box سے ایک ایسے نظام میں بدل دیتی ہے جس کے بارے میں آپ سوچ اور اسے آپریٹ کر سکتے ہیں، اس لیے یہ کسی بھی middle-یا-اوپر کے انجینئر کے لیے مرکزی علم ہے۔ **control plane** فیصلہ ساز دماغ ہے: **kube-apiserver** وہ واحد سامنے کا دروازہ ہے جس کے ذریعے ہر جزو اور صارف بات چیت کرتا ہے؛ **etcd** وہ مطابقت رکھنے والا key-value store ہے جو پورے cluster کی حالت رکھتا ہے اور سچائی کا سرچشمہ ہے (اسے کھونے کا مطلب cluster کو کھونا)؛ **scheduler** فیصلہ کرتا ہے کہ ہر نیا Pod کس node پر اترتا ہے؛ اور **controller-manager** وہ reconciliation loops چلاتا ہے جو اصل حالت کو مسلسل مطلوبہ حالت کی طرف چلاتے ہیں۔ ہر **worker node** پر، **kubelet** وہ agent ہے جو node کے containers کو اُن Pods سے میل کراتا ہے جو اسے تفویض کیے گئے ہیں، **kube-proxy** وہ networking پروگرام کرتا ہے جو Service virtual IPs کو درست Pods کی طرف route کرتی ہے، اور ایک **container runtime** (containerd، CRI-O) حقیقتاً containers چلاتا ہے۔ یہ دیکھنا کہ ایک اکیلا `kubectl apply` اس نظام میں کیسے بہتا ہے — apiserver سے etcd تک، controllers objects بناتے، scheduler Pods رکھتا، kubelets containers شروع کرتے، kube-proxy networking جوڑتا، سب watch-and-reconcile loops کے طور پر — پلیٹ فارم کے پیچھے کے خوبصورت، مطابقت رکھنے والے ڈیزائن کو آشکار کرتا ہے۔ یہی ذہنی ماڈل بالکل وہ چیز ہے جس کی آپ کو ضرورت ہوتی ہے یہ debug کرنے کے لیے کہ کوئی Pod Pending پر کیوں اٹکا ہے (scheduler)، cluster جواب کیوں نہیں دے رہا (apiserver/etcd)، یا کوئی Service route کیوں نہیں کر رہا (kube-proxy)، جو اسے حقیقی clusters کو چلانے اور مسائل حل کرنے کے لیے ناگزیر بنا دیتا ہے۔

بڑی تصویر

Control plane کے اجزا

Worker node کے اجزا

ایک "kubectl apply" نظام میں کیسے بہتا ہے

یہ کیوں اہم ہے

متعلقہ سوالات