Bayyana gine-ginen Kubernetes: control plane da worker nodes da ɓangarorinsu.

Question

IT Interview Practice · Accepted Answer

Cluster na Kubernetes yana da nau'ikan injuna guda biyu: **control plane** ("kwakwalwa" da ke yanke shawara ya ajiye yanayi) da **worker nodes** (inda Pod ɗinka ke gudana da gaske). Kowanne yana da ƙaramin tarin ɓangarori masu bayyanannun ayyuka.

## Babbar hoto

```text
┌──────────────── CONTROL PLANE (kwakwalwa) ────────────────┐
│                                                            │
│   kube-apiserver ── ƙofar gaba; DUK sadarwa na ratsawa ta ciki│
│        │                                                   │
│   etcd ───────── key-value store: TUSHEN GASKIYA na        │
│                  cluster (duk abubuwa & yanayin da ake so)  │
│   kube-scheduler ── yana yanke WACE node sabon Pod zai gudana│
│   controller-manager ── yana gudanar da control loops (reconcilers)│
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (app ɗinka) │ │  └ Pods (app ɗinka) │
└─────────────────────┘ └─────────────────────┘
```

## Ɓangarorin control plane

```text
kube-apiserver        Ƙofar shiga ɗaya tak. Yana fito da REST API; yana tantancewa &
                      ajiye abubuwa a etcd. kubectl, controllers, da kubelets
                      duk suna magana KAWAI da apiserver.
etcd                  Rarrabe, key-value store mai daidaito. Yana riƙe GABA ƊAYA
                      yanayin cluster (da ake so + na yanzu). Rasa etcd = rasa cluster.
kube-scheduler        Yana kallon Pod da ba a sanya wa node ba ya kuma zaɓi mafi kyawun node
                      (bisa resource requests, affinity, taints, da sauransu).
kube-controller-      Yana gudanar da control loops: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, da sauransu. Kowace loop na tuƙa gaske → da ake so.
cloud-controller-     (A cloud) yana haɗi da mai bayarwa: load balancers, routes,
manager               tsawon rayuwar node.
```

## Ɓangarorin worker node

```text
kubelet          Wakilin node. Yana magana da apiserver, yana kunna/kashe container ta
                 runtime, ya kuma bayar da rahoton matsayin Pod & node. Yana sa gaskiyar
                 node ta yi daidai da Pod da aka sanya masa.
kube-proxy       Yana tsara hanyar sadarwar node (iptables/IPVS) don IP na kama-da-wane
                 na Service su sami load-balance zuwa daidaitattun Pod endpoints.
container runtime Software da ke gudanar da container da gaske (containerd, CRI-O).
```

## Yadda "kubectl apply" ke ratsawa cikin tsarin

```text
1. kubectl → kube-apiserver: "Ina son Deployment mai replica 3"
2. apiserver yana tantancewa & rubuta abin zuwa etcd
3. controller-manager (deployment→replicaset controller) ya gan shi, ya ƙirƙira Pod abubuwa 3
4. scheduler ya ga Pod 3 marasa sanyawa, ya sanya kowanne zuwa node (ya sake rubutawa ta apiserver)
5. kubelet na kowane node ya ga Pod ɗinsa, ya gaya wa runtime ya ja images ya kunna container
6. kube-proxy ya haɗa hanyar sadarwar Service don zirga-zirga ta isa sabbin Pod
Komai WATCH + RECONCILE loop ne wanda apiserver ke sasantawa.
```

```bash
kubectl get nodes                 # jera nodes (control-plane + workers)
kubectl get pods -n kube-system   # duba control-plane / system components
kubectl get componentstatuses     # lafiyar manyan ɓangarorin control-plane
```

## Me ya sa yake da muhimmanci

Fahimtar rarrabuwa tsakanin control plane da worker nodes — da matsayin kowane ɓangare — shine abin da ke mai da Kubernetes daga akwati mai duhu zuwa tsari da za ka iya yin tunani a kai ka kuma gudanar da shi, don haka babban ilimi ne ga kowane injiniya na tsaka-tsaki-ko-sama. **Control plane** shine kwakwalwar yanke shawara: **kube-apiserver** shine ƙofar gaba ɗaya tak da kowane ɓangare da mai amfani ke sadarwa ta ciki; **etcd** shine key-value store mai daidaito da ke riƙe gaba ɗayan yanayin cluster kuma shine tushen gaskiya (rasa shi na nufin rasa cluster); **scheduler** yana yanke wace node kowane sabon Pod zai sauka; kuma **controller-manager** yana gudanar da reconciliation loops waɗanda ke ci gaba da tuƙa yanayin gaske zuwa yanayin da ake so. A kowane **worker node**, **kubelet** shine wakilin da ke sa container na node su yi daidai da Pod da aka sanya masa, **kube-proxy** yana tsara hanyar sadarwa da ke sa IP na kama-da-wane na Service tuƙa zuwa daidaitattun Pod, kuma **container runtime** (containerd, CRI-O) yana gudanar da container da gaske. Ganin yadda `kubectl apply` guda ke ratsawa cikin wannan tsarin — apiserver zuwa etcd, controllers suna ƙirƙira abubuwa, scheduler yana sanya Pod, kubelets suna kunna container, kube-proxy yana haɗa hanyar sadarwa, duka a matsayin watch-and-reconcile loops — yana bayyana ƙirar kyakkyawa, mai daidaito da ke bayan dandalin. Wannan tsarin tunani shine ainihin abin da kake buƙata don gyara dalilin da yasa Pod ya makale a Pending (scheduler), me yasa cluster ba ya amsawa (apiserver/etcd), ko me yasa Service ba ya tuƙawa (kube-proxy), yana mai da shi mai mahimmanci don gudanarwa da magance matsalar ainihin clusters.

Babbar hoto

Ɓangarorin control plane

Ɓangarorin worker node

Yadda "kubectl apply" ke ratsawa cikin tsarin

Me ya sa yake da muhimmanci

Tambayoyi masu alaƙa