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

```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 components पहा
kubectl get componentstatuses     # मुख्य control-plane भागांचे आरोग्य
```

## हे का महत्त्वाचे आहे

control plane आणि worker nodes मधील विभागणी — आणि प्रत्येक component ची भूमिका — समजून घेणे हेच Kubernetes ला एका black box मधून तुम्ही ज्याबद्दल विचार करू व चालवू शकता अशा सिस्टीममध्ये बदलते, त्यामुळे कोणत्याही middle-किंवा-वरच्या engineer साठी हे मूलभूत ज्ञान आहे. **control plane** हा निर्णय घेणारा मेंदू आहे: **kube-apiserver** हे एकमेव front door आहे ज्यातून प्रत्येक component व user संवाद साधतो; **etcd** हा consistent key-value store आहे जो संपूर्ण cluster state धारण करतो आणि source of truth आहे (तो गमावणे म्हणजे cluster गमावणे); **scheduler** प्रत्येक नवीन Pod कोणत्या node वर पडेल ते ठरवतो; आणि **controller-manager** reconciliation loops चालवतो जे प्रत्यक्ष 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 म्हणून — प्लॅटफॉर्मामागील सुरेख, सुसंगत रचना उघड करते. Pod का Pending मध्ये अडकला आहे (scheduler), cluster का प्रतिसाद देत नाही (apiserver/etcd), किंवा Service का route करत नाही (kube-proxy) हे debug करण्यासाठी नेमके हेच मानसिक model तुम्हाला लागते, त्यामुळे खरे clusters चालवण्यासाठी व troubleshoot करण्यासाठी ते अपरिहार्य ठरते.

एकंदर चित्र

Control plane components

Worker node components

एक "kubectl apply" सिस्टीममधून कसे वाहते

हे का महत्त्वाचे आहे

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