Kubernetes को architecture वर्णन गर्नुहोस्: control plane बनाम worker node र तिनका घटकहरू।

Question

IT Interview Practice · Accepted Answer

एउटा Kubernetes cluster मा दुई किसिमका मेसिन हुन्छन्: **control plane** (निर्णय लिने र state भण्डारण गर्ने "मस्तिष्क") र **worker node** हरू (जहाँ तपाईंका Pod वास्तवमा चल्छन्)। प्रत्येकसँग राम्ररी परिभाषित घटकहरूको सानो समूह हुन्छ।

## समग्र चित्र

```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                 # node हरू सूचीबद्ध गर्नुहोस् (control-plane + worker)
kubectl get pods -n kube-system   # control-plane / system घटकहरू हेर्नुहोस्
kubectl get componentstatuses     # मुख्य control-plane भागहरूको स्वास्थ्य
```

## यो किन महत्त्वपूर्ण छ

Control plane र worker node बीचको विभाजन — र प्रत्येक घटकको भूमिका — बुझ्नाले Kubernetes लाई एउटा black box बाट तपाईंले तर्क गर्न र सञ्चालन गर्न सक्ने सिस्टममा बदल्छ, त्यसैले यो कुनै पनि middle-वा-माथिका इन्जिनियरका लागि मुख्य ज्ञान हो। **Control plane** निर्णय लिने मस्तिष्क हो: **kube-apiserver** एउटै front door हो जसमार्फत हरेक घटक र प्रयोगकर्ताले सञ्चार गर्छन्; **etcd** consistent key-value store हो जसले सिंगो cluster state राख्छ र truth को स्रोत हो (यो गुमाउनु भनेको cluster नै गुमाउनु); **scheduler** ले प्रत्येक नयाँ Pod कुन node मा पर्ने भन्ने निर्णय गर्छ; र **controller-manager** ले reconciliation loop हरू चलाउँछ जसले वास्तविक state लाई निरन्तर desired state तर्फ लैजान्छ। प्रत्येक **worker node** मा, **kubelet** त्यो agent हो जसले node का container हरूलाई त्यसमा तोकिएका Pod सँग मिलाउँछ, **kube-proxy** ले Service virtual IP हरू सही Pod मा route हुने networking program गर्छ, र एउटा **container runtime** (containerd, CRI-O) ले वास्तवमा container चलाउँछ। एउटै `kubectl apply` यो सिस्टमभर कसरी बग्छ भन्ने देख्नु — apiserver बाट etcd, controller ले object बनाउने, scheduler ले Pod राख्ने, kubelet ले container सुरु गर्ने, kube-proxy ले networking जोड्ने, सबै watch-and-reconcile loop का रूपमा — प्लेटफर्म पछाडिको सुरुचिपूर्ण, सुसंगत डिजाइन उजागर गर्छ। यो मानसिक मोडेल नै तपाईंलाई किन एउटा Pod Pending मा अड्किएको छ (scheduler), किन cluster ले जवाफ दिइरहेको छैन (apiserver/etcd), वा किन Service route गरिरहेको छैन (kube-proxy) भनी debug गर्न चाहिने कुरा हो, जसले यसलाई वास्तविक cluster सञ्चालन र समस्या-समाधानका लागि अपरिहार्य बनाउँछ।

समग्र चित्र

Control plane का घटकहरू

Worker node का घटकहरू

एउटा "kubectl apply" सिस्टमभर कसरी बग्छ

यो किन महत्त्वपूर्ण छ

सम्बन्धित प्रश्नहरू