Kubernetes architecture ਦਾ ਵਰਣਨ ਕਰੋ: control plane ਬਨਾਮ worker nodes ਅਤੇ ਉਹਨਾਂ ਦੇ components।

Question

IT Interview Practice · Accepted Answer

ਇੱਕ Kubernetes cluster ਵਿੱਚ ਦੋ ਕਿਸਮ ਦੀਆਂ ਮਸ਼ੀਨਾਂ ਹੁੰਦੀਆਂ ਹਨ: **control plane** ("ਦਿਮਾਗ਼" ਜੋ ਫ਼ੈਸਲੇ ਲੈਂਦਾ ਹੈ ਅਤੇ state ਸਟੋਰ ਕਰਦਾ ਹੈ) ਅਤੇ **worker nodes** (ਜਿੱਥੇ ਤੁਹਾਡੇ 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        ਇਕੱਲਾ ਪ੍ਰਵੇਸ਼ ਬਿੰਦੂ। REST API ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ; object ਨੂੰ validate ਕਰਦਾ ਤੇ
                      etcd ਵਿੱਚ persist ਕਰਦਾ ਹੈ। kubectl, controllers, ਤੇ kubelets
                      ਸਾਰੇ ਸਿਰਫ਼ apiserver ਨਾਲ ਗੱਲ ਕਰਦੇ ਹਨ।
etcd                  ਵੰਡਿਆ, ਇਕਸਾਰ key-value store। ਪੂਰੀ cluster state ਰੱਖਦਾ ਹੈ
                      (desired + current)। etcd ਗਵਾਓ = cluster ਗਵਾਓ।
kube-scheduler        ਬਿਨਾਂ node ਦੇ Pod ਲਈ ਵੇਖਦਾ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ node ਚੁਣਦਾ ਹੈ
                      (resource request, affinity, taint, ਆਦਿ ਦੇ ਆਧਾਰ 'ਤੇ)।
kube-controller-      control loops ਚਲਾਉਂਦਾ ਹੈ: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, ਆਦਿ। ਹਰ loop ਅਸਲ → desired ਚਲਾਉਂਦਾ ਹੈ।
cloud-controller-     (cloud 'ਤੇ) provider ਨਾਲ integrate ਕਰਦਾ ਹੈ: load balancers, routes,
manager               node lifecycle।
```

## Worker node components

```text
kubelet          node ਦਾ agent। apiserver ਨਾਲ ਗੱਲ ਕਰਦਾ, runtime ਰਾਹੀਂ container start/stop
                 ਕਰਦਾ, ਤੇ Pod ਤੇ node status ਦੀ report ਕਰਦਾ ਹੈ। ਇਹ node ਦੀ ਹਕੀਕਤ ਨੂੰ ਇਸਨੂੰ
                 ਸੌਂਪੇ Pod ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਬਣਾਉਂਦਾ ਹੈ।
kube-proxy       node ਦੀ networking (iptables/IPVS) program ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ Service virtual
                 IP ਸਹੀ Pod endpoint ਵੱਲ load-balance ਹੋਣ।
container runtime ਉਹ software ਜੋ ਅਸਲ ਵਿੱਚ container ਚਲਾਉਂਦਾ ਹੈ (containerd, CRI-O)।
```

## ਇੱਕ "kubectl apply" system ਵਿੱਚੋਂ ਕਿਵੇਂ ਵਗਦਾ ਹੈ

```text
1. kubectl → kube-apiserver: "ਮੈਨੂੰ 3 replica ਵਾਲਾ ਇੱਕ Deployment ਚਾਹੀਦਾ ਹੈ"
2. apiserver object ਨੂੰ validate ਕਰਦਾ ਤੇ etcd ਵਿੱਚ ਲਿਖਦਾ ਹੈ
3. controller-manager (deployment→replicaset controller) ਇਸਨੂੰ ਵੇਖ ਕੇ 3 Pod object ਬਣਾਉਂਦਾ ਹੈ
4. scheduler 3 ਬਿਨਾਂ-ਸੌਂਪੇ Pod ਵੇਖਦਾ ਹੈ, ਹਰ ਇੱਕ ਨੂੰ ਇੱਕ node ਸੌਂਪਦਾ ਹੈ (apiserver ਰਾਹੀਂ ਵਾਪਸ ਲਿਖਦਾ ਹੈ)
5. ਹਰ node ਦਾ kubelet ਆਪਣੇ Pod ਵੇਖਦਾ ਹੈ, runtime ਨੂੰ image pull ਤੇ container start ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ
6. kube-proxy Service networking ਜੋੜਦਾ ਹੈ ਤਾਂ ਜੋ traffic ਨਵੇਂ Pod ਤੱਕ ਪਹੁੰਚੇ
ਹਰ ਚੀਜ਼ apiserver ਦੁਆਰਾ ਵਿਚੋਲਗੀ ਕੀਤੀ ਇੱਕ WATCH + RECONCILE loop ਹੈ।
```

```bash
kubectl get nodes                 # node ਸੂਚੀਬੱਧ ਕਰੋ (control-plane + workers)
kubectl get pods -n kube-system   # control-plane / system components ਵੇਖੋ
kubectl get componentstatuses     # ਮੁੱਖ control-plane ਟੁਕੜਿਆਂ ਦੀ ਸਿਹਤ
```

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

Control plane ਅਤੇ worker nodes ਵਿਚਕਾਰ ਵੰਡ — ਅਤੇ ਹਰ component ਦੀ ਭੂਮਿਕਾ — ਨੂੰ ਸਮਝਣਾ ਹੀ ਉਹ ਹੈ ਜੋ Kubernetes ਨੂੰ ਇੱਕ ਕਾਲੇ ਡੱਬੇ ਤੋਂ ਇੱਕ ਅਜਿਹੇ system ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ ਸੋਚ ਅਤੇ ਪਰਿਚਾਲਿਤ ਕਰ ਸਕਦੇ ਹੋ, ਇਸ ਲਈ ਇਹ ਕਿਸੇ ਵੀ middle-ਜਾਂ-ਉੱਪਰ engineer ਲਈ ਮੁੱਖ ਗਿਆਨ ਹੈ। **Control plane** ਫ਼ੈਸਲਾ ਲੈਣ ਵਾਲਾ ਦਿਮਾਗ਼ ਹੈ: **kube-apiserver** ਇਕੱਲਾ ਮੁੱਖ ਦਰਵਾਜ਼ਾ ਹੈ ਜਿਸ ਰਾਹੀਂ ਹਰ component ਅਤੇ user ਸੰਚਾਰ ਕਰਦਾ ਹੈ; **etcd** ਇਕਸਾਰ key-value store ਹੈ ਜੋ ਪੂਰੀ cluster state ਰੱਖਦਾ ਹੈ ਅਤੇ source of truth ਹੈ (ਇਸਨੂੰ ਗਵਾਉਣ ਦਾ ਮਤਲਬ cluster ਗਵਾਉਣਾ ਹੈ); **scheduler** ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਹਰ ਨਵਾਂ Pod ਕਿਹੜੇ node 'ਤੇ ਉੱਤਰਦਾ ਹੈ; ਅਤੇ **controller-manager** reconciliation loops ਚਲਾਉਂਦਾ ਹੈ ਜੋ ਲਗਾਤਾਰ ਅਸਲ state ਨੂੰ desired state ਵੱਲ ਚਲਾਉਂਦੇ ਹਨ। ਹਰ **worker node** 'ਤੇ, **kubelet** ਉਹ agent ਹੈ ਜੋ node ਦੇ container ਨੂੰ ਇਸਨੂੰ ਸੌਂਪੇ Pod ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਬਣਾਉਂਦਾ ਹੈ, **kube-proxy** ਉਹ networking program ਕਰਦਾ ਹੈ ਜੋ Service virtual IP ਨੂੰ ਸਹੀ Pod ਵੱਲ route ਕਰਦੀ ਹੈ, ਅਤੇ ਇੱਕ **container runtime** (containerd, CRI-O) ਅਸਲ ਵਿੱਚ container ਚਲਾਉਂਦਾ ਹੈ। ਇਹ ਵੇਖਣਾ ਕਿ ਇੱਕ ਇਕੱਲਾ `kubectl apply` ਇਸ system ਵਿੱਚੋਂ ਕਿਵੇਂ ਵਗਦਾ ਹੈ — apiserver ਤੋਂ etcd, controllers object ਬਣਾਉਂਦੇ, scheduler Pod ਰੱਖਦਾ, kubelets container start ਕਰਦੇ, kube-proxy networking ਜੋੜਦਾ, ਸਭ watch-and-reconcile loops ਵਜੋਂ — ਪਲੇਟਫਾਰਮ ਦੇ ਪਿੱਛੇ ਦੀ ਸੁੰਦਰ, ਇਕਸਾਰ ਡਿਜ਼ਾਈਨ ਨੂੰ ਪ੍ਰਗਟ ਕਰਦਾ ਹੈ। ਇਹ ਮਾਨਸਿਕ ਮਾਡਲ ਠੀਕ ਉਹੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਇਹ debug ਕਰਨ ਲਈ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕੋਈ Pod Pending 'ਤੇ ਕਿਉਂ ਫਸਿਆ (scheduler), cluster ਕਿਉਂ ਜਵਾਬ ਨਹੀਂ ਦੇ ਰਿਹਾ (apiserver/etcd), ਜਾਂ ਕੋਈ Service route ਕਿਉਂ ਨਹੀਂ ਕਰ ਰਿਹਾ (kube-proxy), ਜੋ ਇਸਨੂੰ ਅਸਲ cluster ਪਰਿਚਾਲਿਤ ਕਰਨ ਅਤੇ troubleshoot ਕਰਨ ਲਈ ਲਾਜ਼ਮੀ ਬਣਾਉਂਦਾ ਹੈ।

ਵੱਡੀ ਤਸਵੀਰ

Control plane components

Worker node components

ਇੱਕ "kubectl apply" system ਵਿੱਚੋਂ ਕਿਵੇਂ ਵਗਦਾ ਹੈ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ