Eleza usanifu wa Kubernetes: control plane dhidi ya worker nodes na vipengele vyake.

Question

IT Interview Practice · Accepted Answer

Cluster ya Kubernetes ina aina mbili za mashine: **control plane** ("ubongo" unaofanya maamuzi na kuhifadhi hali) na **worker nodes** (ambapo Pods zako huendeshwa kihalisia). Kila moja ina seti ndogo ya vipengele vilivyofafanuliwa vizuri.

## Picha kubwa

```text
┌──────────────── CONTROL PLANE (ubongo) ───────────────────┐
│                                                            │
│   kube-apiserver ── mlango wa mbele; mawasiliano YOTE hupita│
│        │                                                   │
│   etcd ───────── hifadhi ya key-value: CHANZO CHA UKWELI   │
│                  cha cluster (vitu vyote & hali unayotaka) │
│   kube-scheduler ── huamua Pod mpya inaendeshwa kwenye node IPI│
│   controller-manager ── huendesha control loops (reconcilers)│
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pods (apps zako) │ │  └ Pods (apps zako) │
└─────────────────────┘ └─────────────────────┘
```

## Vipengele vya control plane

```text
kube-apiserver        Mlango pekee wa kuingia. Hufunua REST API; huthibitisha na
                      huhifadhi vitu kwenye etcd. kubectl, controllers, na kubelets
                      wote huongea NA apiserver pekee.
etcd                  Hifadhi ya key-value iliyosambaa, thabiti. Hushikilia hali YOTE
                      ya cluster (unayotaka + ya sasa). Kupoteza etcd = kupoteza cluster.
kube-scheduler        Huchunguza Pods zisizo na node na huchagua node bora zaidi
                      (kulingana na resource requests, affinity, taints, n.k.).
kube-controller-      Huendesha control loops: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, n.k. Kila loop huendesha halisi → unayotaka.
cloud-controller-     (Kwenye cloud) huunganisha na provider: load balancers, routes,
manager               mzunguko wa maisha ya node.
```

## Vipengele vya worker node

```text
kubelet          Wakala wa node. Huongea na apiserver, huanzisha/huzima containers kupitia
                 runtime, na huripoti hali ya Pod na node. Hufanya uhalisia wa node
                 ulingane na Pods zilizopangwa kwake.
kube-proxy       Hupanga mtandao wa node (iptables/IPVS) ili IP pepe za Service
                 zi-load-balance kwa endpoints sahihi za Pod.
container runtime Programu inayoendesha containers kihalisia (containerd, CRI-O).
```

## Jinsi "kubectl apply" inavyopita kwenye mfumo

```text
1. kubectl → kube-apiserver: "Nataka Deployment yenye replicas 3"
2. apiserver huthibitisha na huandika kitu kwenye etcd
3. controller-manager (deployment→replicaset controller) huikiona, huunda vitu 3 vya Pod
4. scheduler huona Pods 3 zisizopangwa, hupanga kila moja kwenye node (huandika kupitia apiserver)
5. kubelet ya kila node huona Pods zake, huambia runtime ivute images na ianzishe containers
6. kube-proxy huunganisha mtandao wa Service ili trafiki ifikie Pods mpya
Kila kitu ni loop ya WATCH + RECONCILE inayosuluhishwa na apiserver.
```

```bash
kubectl get nodes                 # orodhesha nodes (control-plane + workers)
kubectl get pods -n kube-system   # ona vipengele vya control-plane / system
kubectl get componentstatuses     # afya ya vipande vya msingi vya control-plane
```

## Kwa nini ni muhimu

Kuelewa mgawanyo kati ya control plane na worker nodes — na jukumu la kila kipengele — ndicho kinachogeuza Kubernetes kutoka sanduku jeusi kuwa mfumo unaoweza kuufikiria na kuuendesha, hivyo ni maarifa ya msingi kwa mhandisi yeyote wa ngazi ya kati na juu. **Control plane** ni ubongo unaofanya maamuzi: **kube-apiserver** ni mlango pekee wa mbele ambao kila kipengele na mtumiaji huwasiliana kupitia kwake; **etcd** ni hifadhi thabiti ya key-value inayoshikilia hali yote ya cluster na ni chanzo cha ukweli (kuipoteza ni kupoteza cluster); **scheduler** huamua kila Pod mpya inatua kwenye node ipi; na **controller-manager** huendesha reconciliation loops zinazoendesha hali halisi kuelekea hali unayotaka kila mara. Kwenye kila **worker node**, **kubelet** ni wakala anayefanya containers za node zilingane na Pods zilizopangwa kwake, **kube-proxy** hupanga mtandao unaofanya IP pepe za Service zielekeze kwa Pods sahihi, na **container runtime** (containerd, CRI-O) huendesha containers kihalisia. Kuona jinsi `kubectl apply` moja inavyopita kwenye mfumo huu — apiserver hadi etcd, controllers zikiunda vitu, scheduler ikiweka Pods, kubelets zikianzisha containers, kube-proxy ikiunganisha mtandao, yote kama watch-and-reconcile loops — huonyesha ubunifu wa kifahari na thabiti nyuma ya jukwaa. Modeli hii ya kimawazo ndiyo hasa unayohitaji ku-debug kwa nini Pod imekwama Pending (scheduler), kwa nini cluster haijibu (apiserver/etcd), au kwa nini Service haielekezi (kube-proxy), ikiifanya isiyoepukika kwa kuendesha na kutatua matatizo ya clusters halisi.

Picha kubwa

Vipengele vya control plane

Vipengele vya worker node

Jinsi "kubectl apply" inavyopita kwenye mfumo

Kwa nini ni muhimu

Maswali yanayohusiana