Kubernetes આર્કિટેક્ચર વર્ણવો: control plane vs worker nodes અને તેમના ઘટકો.

Question

IT Interview Practice · Accepted Answer

એક Kubernetes cluster માં બે પ્રકારના મશીનો હોય છે: **control plane** (એ "મગજ" જે નિર્ણયો લે છે અને state સંગ્રહે છે) અને **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 માંથી એવી સિસ્ટમમાં ફેરવે છે જેના વિશે તમે વિચારી અને તેને operate કરી શકો, તેથી કોઈપણ middle-કે-ઉપરના engineer માટે એ કેન્દ્રિય જ્ઞાન છે. **control plane** એ નિર્ણય લેનારું મગજ છે: **kube-apiserver** એ એકમાત્ર front door છે જેના દ્વારા દરેક ઘટક અને user સંવાદ કરે છે; **etcd** એ consistent key-value store છે જે આખું cluster state ધરાવે છે અને source of truth છે (તેને ગુમાવવો એટલે cluster ગુમાવવો); **scheduler** નક્કી કરે છે કે દરેક નવો Pod કયા node પર ઊતરે; અને **controller-manager** reconciliation loops ચલાવે છે જે સતત actual state ને desired state તરફ દોરી જાય છે. દરેક **worker node** પર, **kubelet** એ agent છે જે node ના containers ને તેને સોંપાયેલા Pods સાથે મેળ ખવડાવે છે, **kube-proxy** એ networking program કરે છે જે 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 તરીકે — એ પ્લેટફોર્મ પાછળની સુઘડ, consistent ડિઝાઇન છતી કરે છે. આ માનસિક મોડલ બરાબર એ જ છે જે તમને debug કરવા જોઈએ કે Pod કેમ Pending માં અટકી ગયો છે (scheduler), cluster કેમ પ્રતિસાદ આપતું નથી (apiserver/etcd), કે Service કેમ route કરતું નથી (kube-proxy), જે તેને વાસ્તવિક clusters ને operate અને troubleshoot કરવા માટે અનિવાર્ય બનાવે છે.

મોટું ચિત્ર

Control plane ઘટકો

Worker node ઘટકો

એક "kubectl apply" સિસ્ટમમાંથી કેવી રીતે વહે છે

આ શા માટે મહત્વનું છે

સંબંધિત પ્રશ્નો