Kubernetes architectureను వివరించండి: control plane vs worker nodes మరియు వాటి components.

Question

IT Interview Practice · Accepted Answer

ఒక Kubernetes clusterలో రెండు రకాల machines ఉంటాయి: **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                  Distributed, consistent 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
                 start/stop చేస్తుంది, Pod & node status report చేస్తుంది. దానికి కేటాయించిన
                 Podsకు node వాస్తవాన్ని సరిపోయేలా చేస్తుంది.
kube-proxy       node networkingను (iptables/IPVS) program చేస్తుంది; తద్వారా Service virtual
                 IPs సరైన Pod endpointsకు load-balance అవుతాయి.
container runtime నిజంగా containers నడిపే software (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 unassigned Pods చూసి, ఒక్కొక్కదాన్ని ఒక nodeకు కేటాయిస్తుంది (apiserver ద్వారా తిరిగి వ్రాస్తుంది)
5. ప్రతి node యొక్క kubelet తన Pods చూసి, images pull చేసి containers start చేయమని runtimeకు చెబుతుంది
6. kube-proxy Service networking wire చేస్తుంది, తద్వారా 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     # core control-plane భాగాల ఆరోగ్యం
```

## ఇది ఎందుకు ముఖ్యం

control plane మరియు worker nodes మధ్య విభజన — మరియు ప్రతి component పాత్ర — అర్థం చేసుకోవడం Kubernetesను ఒక black box నుండి మీరు reason చేసి operate చేయగల ఒక systemగా మారుస్తుంది, కాబట్టి ఇది ఏ middle-లేదా-పైన engineerకైనా ప్రధాన జ్ఞానం. **control plane** అనేది నిర్ణయాలు తీసుకునే మెదడు: **kube-apiserver** అనేది ప్రతి component మరియు user communicate చేసే ఏకైక front door; **etcd** అనేది మొత్తం cluster state కలిగి ఉన్న consistent key-value store మరియు source of truth (దాన్ని కోల్పోవడం అంటే clusterను కోల్పోవడం); **scheduler** ప్రతి కొత్త Pod ఏ nodeపై దిగుతుందో నిర్ణయిస్తుంది; మరియు **controller-manager** వాస్తవ stateను desired state వైపు నిరంతరం నడిపే reconciliation loops నడుపుతుంది. ప్రతి **worker node**పై, **kubelet** అనేది node containersను దానికి కేటాయించిన Podsకు సరిపోయేలా చేసే agent, **kube-proxy** Service virtual IPs సరైన Podsకు route అయ్యేలా చేసే networking program చేస్తుంది, మరియు ఒక **container runtime** (containerd, CRI-O) నిజంగా containers నడుపుతుంది. ఒక్క `kubectl apply` ఈ system గుండా ఎలా ప్రవహిస్తుందో చూడటం — apiserver నుండి etcd, controllers objects సృష్టించడం, scheduler Pods ఉంచడం, kubelets containers start చేయడం, kube-proxy networking wire చేయడం, అన్నీ watch-and-reconcile loopsగా — platform వెనుక ఉన్న elegant, consistent designను వెల్లడిస్తుంది. ఒక Pod ఎందుకు Pendingలో ఇరుక్కుంది (scheduler), cluster ఎందుకు స్పందించడం లేదు (apiserver/etcd), లేదా ఒక Service ఎందుకు route చేయడం లేదు (kube-proxy) అనేది debug చేయడానికి మీకు కావలసిన మానసిక model ఇదే, ఇది నిజ clusters operate మరియు troubleshoot చేయడానికి అనివార్యం చేస్తుంది.

మొత్తం చిత్రం

Control plane components

Worker node components

ఒక "kubectl apply" వ్యవస్థ గుండా ఎలా ప్రవహిస్తుంది

ఇది ఎందుకు ముఖ్యం

సంబంధిత ప్రశ్నలు