Kubernetes आर्किटेक्चर का वर्णन करें: control plane बनाम worker nodes और उनके components।

Question

IT Interview Practice · Accepted Answer

एक Kubernetes cluster में दो तरह की मशीनें होती हैं: **control plane** (वह "मस्तिष्क" जो निर्णय लेता है और state संग्रहीत करता है) और **worker nodes** (जहाँ आपके Pods असल में चलते हैं)। हर एक में सुपरिभाषित components का एक छोटा समूह होता है।

## बड़ी तस्वीर

```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 components

```text
kube-apiserver        एकमात्र प्रवेश बिंदु। REST API उजागर करता है; objects को
                      validate कर etcd में persist करता है। kubectl, controllers और
                      kubelets सभी केवल apiserver से बात करते हैं।
etcd                  वितरित, सुसंगत key-value store। पूरे cluster की state (desired +
                      current) रखता है। etcd खोना = cluster खोना।
kube-scheduler        बिना node वाले Pods पर नज़र रखता है और सबसे अच्छा node चुनता है
                      (resource requests, affinity, taints, आदि के आधार पर)।
kube-controller-      control loops चलाता है: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, आदि। हर loop actual → desired ले जाता है।
cloud-controller-     (cloud पर) provider के साथ integrate करता है: load balancers, routes,
manager               node lifecycle।
```

## Worker node components

```text
kubelet          node agent। apiserver से बात करता है, runtime के ज़रिए containers
                 शुरू/बंद करता है, और Pod व node status रिपोर्ट करता है। यह node की
                 वास्तविकता को उसे सौंपे गए Pods से मिलाता है।
kube-proxy       node की networking (iptables/IPVS) प्रोग्राम करता है ताकि Service virtual
                 IPs सही Pod endpoints पर load-balance हों।
container runtime वह software जो असल में containers चलाता है (containerd, CRI-O)।
```

## एक "kubectl apply" सिस्टम से कैसे बहता है

```text
1. kubectl → kube-apiserver: "मुझे 3 replicas वाला एक Deployment चाहिए"
2. apiserver object को validate करता है और etcd में लिखता है
3. controller-manager (deployment→replicaset controller) इसे देखता है, 3 Pod objects बनाता है
4. scheduler 3 बिना-सौंपे Pods देखता है, हर एक को एक node सौंपता है (apiserver से वापस लिखता है)
5. हर node का kubelet अपने Pods देखता है, runtime को images pull कर containers शुरू करने कहता है
6. kube-proxy Service networking जोड़ता है ताकि traffic नए Pods तक पहुँचे
सब कुछ apiserver द्वारा मध्यस्थ एक WATCH + RECONCILE loop है।
```

```bash
kubectl get nodes                 # nodes की सूची (control-plane + workers)
kubectl get pods -n kube-system   # control-plane / system components देखें
kubectl get componentstatuses     # मुख्य control-plane हिस्सों का स्वास्थ्य
```

## यह क्यों महत्वपूर्ण है

control plane और worker nodes के बीच विभाजन — और हर component की भूमिका — को समझना ही वह चीज़ है जो Kubernetes को एक black box से एक ऐसे सिस्टम में बदल देती है जिसके बारे में आप तर्क कर सकते हैं और उसे संचालित कर सकते हैं, इसलिए यह किसी भी मध्य-या-ऊपर स्तर के इंजीनियर के लिए मूल ज्ञान है। **control plane** निर्णय लेने वाला मस्तिष्क है: **kube-apiserver** एकमात्र सामने का दरवाज़ा है जिससे हर component और उपयोगकर्ता संवाद करता है; **etcd** वह सुसंगत key-value store है जो पूरे cluster की state रखता है और सत्य का स्रोत है (इसे खोना यानी cluster खोना); **scheduler** तय करता है कि हर नया Pod किस node पर उतरे; और **controller-manager** reconciliation loops चलाता है जो लगातार actual state को desired state की ओर ले जाते हैं। हर **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 के रूप में — प्लेटफ़ॉर्म के पीछे के सुरुचिपूर्ण, सुसंगत design को उजागर करता है। यही मानसिक मॉडल आपको ठीक तब चाहिए जब आप debug करें कि कोई Pod Pending क्यों अटका है (scheduler), cluster अप्रतिक्रियाशील क्यों है (apiserver/etcd), या कोई Service route क्यों नहीं कर रहा (kube-proxy), जो इसे असली clusters को संचालित और समस्या-निवारण करने के लिए अनिवार्य बनाता है।

बड़ी तस्वीर

Control plane components

Worker node components

एक "kubectl apply" सिस्टम से कैसे बहता है

यह क्यों महत्वपूर्ण है

संबंधित प्रश्न