Kubernetes architecture ஐ விவரிக்கவும்: control plane vs worker node கள் மற்றும் அவற்றின் components.

Question

IT Interview Practice · Accepted Answer

ஒரு Kubernetes cluster-இல் இரண்டு வகையான machine கள் உள்ளன: **control plane** (முடிவுகளை எடுத்து state ஐ சேமிக்கும் "மூளை") மற்றும் **worker node கள்** (உங்கள் Pod கள் உண்மையில் இயங்கும் இடம்). ஒவ்வொன்றிற்கும் நன்கு வரையறுக்கப்பட்ட 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" system வழியாக எப்படி பாய்கிறது

```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                 # list nodes (control-plane + workers)
kubectl get pods -n kube-system   # see the control-plane / system components
kubectl get componentstatuses     # health of core control-plane pieces
```

## இது ஏன் முக்கியம்

Control plane மற்றும் worker node களுக்கு இடையேயான பிரிவை — மற்றும் ஒவ்வொரு component-இன் பங்கையும் — புரிந்துகொள்வது தான் Kubernetes ஐ ஒரு black box-இலிருந்து நீங்கள் பகுத்தறிந்து இயக்கக்கூடிய ஒரு system ஆக மாற்றுகிறது, எனவே இது எந்த middle-அல்லது-அதற்கு மேல் engineer-க்கும் மைய அறிவு. **Control plane** என்பது முடிவெடுக்கும் மூளை: **kube-apiserver** என்பது ஒவ்வொரு component மற்றும் பயனரும் தொடர்பு கொள்ளும் ஒற்றை front door; **etcd** என்பது முழு cluster state ஐ வைத்திருக்கும் மற்றும் source of truth ஆக இருக்கும் consistent key-value store (அதை இழப்பது cluster ஐ இழப்பதைக் குறிக்கிறது); **scheduler** ஒவ்வொரு புதிய Pod உம் எந்த node-இல் இறங்குகிறது என்பதை முடிவு செய்கிறது; மற்றும் **controller-manager** உண்மையான state ஐ desired state ஐ நோக்கி தொடர்ந்து இயக்கும் reconciliation loop களை இயக்குகிறது. ஒவ்வொரு **worker node**-இலும், **kubelet** என்பது node-இன் container களை அதற்கு ஒதுக்கப்பட்ட Pod களுடன் பொருந்த வைக்கும் agent, **kube-proxy** Service virtual IP கள் சரியான Pod களுக்கு route செய்யும் networking ஐ program செய்கிறது, மற்றும் ஒரு **container runtime** (containerd, CRI-O) உண்மையில் container களை இயக்குகிறது. ஒரு ஒற்றை `kubectl apply` இந்த system வழியாக எப்படிப் பாய்கிறது என்பதைப் பார்ப்பது — apiserver-இலிருந்து etcd-க்கு, controller கள் object களை உருவாக்குகின்றன, scheduler Pod களை வைக்கிறது, kubelet கள் container களைத் தொடங்குகின்றன, kube-proxy networking ஐ இணைக்கிறது, அனைத்தும் watch-and-reconcile loop களாக — platform-க்குப் பின்னால் உள்ள நேர்த்தியான, consistent design ஐ வெளிப்படுத்துகிறது. இந்த மனநிலை model தான் ஒரு Pod ஏன் Pending-இல் சிக்கியுள்ளது (scheduler), cluster ஏன் பதிலளிக்கவில்லை (apiserver/etcd), அல்லது ஒரு Service ஏன் route செய்யவில்லை (kube-proxy) என்பதை debug செய்ய நீங்கள் தேவைப்படுவது சரியாக, இது நிஜமான cluster களை இயக்குவதற்கும் troubleshoot செய்வதற்கும் இன்றியமையாததாக ஆக்குகிறது.

பெரிய படம்

Control plane components

Worker node components

ஒரு "kubectl apply" system வழியாக எப்படி பாய்கிறது

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்