Përshkruaj arkitekturën e Kubernetes: control plane vs worker node dhe komponentët e tyre.

Question

IT Interview Practice · Accepted Answer

Një cluster Kubernetes ka dy lloje makinash: **control plane** ("truri" që merr vendime dhe ruan gjendjen) dhe **worker node** (ku Pod-et e tua funksionojnë vërtet). Secili ka një bashkësi të vogël komponentësh të mirëpërcaktuar.

## Pamja e madhe

```text
┌──────────────── CONTROL PLANE (truri) ────────────────────┐
│                                                            │
│   kube-apiserver ── dera e parë; TË GJITHA komunikimet kalojnë përmes saj│
│        │                                                   │
│   etcd ───────── ruajtje key-value: BURIMI I SË VËRTETËS   │
│                  i cluster-it (të gjitha object-et & gjendja e dëshiruar)│
│   kube-scheduler ── vendos në CILIN node funksionon një Pod i ri│
│   controller-manager ── drejton control loop-et (reconciler)│
└──────────────────────────┬─────────────────────────────────┘
                           │ (apiserver)
   ┌───────────────────────┼───────────────────────┐
┌──┴─── WORKER NODE ──┐ ┌──┴─── WORKER NODE ──┐  ...
│ kubelet             │ │ kubelet             │
│ kube-proxy          │ │ kube-proxy          │
│ container runtime   │ │ container runtime   │
│  └ Pod-e (app-et)   │ │  └ Pod-e (app-et)   │
└─────────────────────┘ └─────────────────────┘
```

## Komponentët e control plane

```text
kube-apiserver        Pika e vetme e hyrjes. Ekspozon REST API-në; validon &
                      persiston object-e në etcd. kubectl, controller-at dhe kubelet-et
                      flasin VETËM me apiserver-in.
etcd                  Ruajtje key-value e shpërndarë, konsistente. Mban TË GJITHË
                      gjendjen e cluster-it (e dëshiruar + aktuale). Humb etcd = humb cluster-in.
kube-scheduler        Vëzhgon Pod-e pa node të caktuar dhe zgjedh node-in më të mirë
                      (bazuar te resource requests, affinity, taint, etj.).
kube-controller-      Drejton control loop-et: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints, etj. Çdo loop çon faktike → e dëshiruar.
cloud-controller-     (Në cloud) integron me provider-in: load balancer, route,
manager               cikli i jetës së node-it.
```

## Komponentët e worker node

```text
kubelet          Agjenti i node-it. Flet me apiserver-in, nis/ndal container-a nëpërmjet
                 runtime-it, dhe raporton statusin e Pod & node. E bën realitetin e node-it
                 të përputhet me Pod-et e caktuar për të.
kube-proxy       Programon networking-un e node-it (iptables/IPVS) që IP-të virtuale
                 të Service-it të bëhen load-balance te endpoint-et e duhura të Pod-eve.
container runtime Software-i që faktikisht drejton container-at (containerd, CRI-O).
```

## Si rrjedh një "kubectl apply" nëpër sistem

```text
1. kubectl → kube-apiserver: "Dua një Deployment me 3 replica"
2. apiserver validon & shkruan object-in në etcd
3. controller-manager (deployment→replicaset controller) e sheh, krijon 3 object Pod
4. scheduler sheh 3 Pod të pacaktuar, cakton secilin te një node (shkruan mbrapsht përmes apiserver)
5. kubelet-i i çdo node sheh Pod-et e tij, i thotë runtime-it të tërheqë image-t & të nisë container-at
6. kube-proxy lidh networking-un e Service-it që trafiku të arrijë Pod-et e reja
Gjithçka është një loop WATCH + RECONCILE i ndërmjetësuar nga apiserver-i.
```

```bash
kubectl get nodes                 # listo node-et (control-plane + worker)
kubectl get pods -n kube-system   # shiko komponentët control-plane / sistem
kubectl get componentstatuses     # shëndeti i pjesëve kryesore control-plane
```

## Pse ka rëndësi

Të kuptuarit e ndarjes midis control plane dhe worker node — dhe rolin e çdo komponenti — është ajo që e kthen Kubernetes nga një kuti e zezë në një sistem mbi të cilin mund të arsyetosh dhe të operosh, kështu që është njohuri thelbësore për çdo inxhinier nga niveli middle e lart. **Control plane** është truri që merr vendime: **kube-apiserver** është dera e vetme e parë përmes së cilës komunikon çdo komponent dhe përdorues; **etcd** është ruajtja konsistente key-value që mban të gjithë gjendjen e cluster-it dhe është burimi i së vërtetës (ta humbësh do të thotë ta humbësh cluster-in); **scheduler** vendos në cilin node aterron çdo Pod i ri; dhe **controller-manager** drejton reconciliation loop-et që çojnë vazhdimisht gjendjen faktike drejt gjendjes së dëshiruar. Në çdo **worker node**, **kubelet** është agjenti që i bën container-at e node-it të përputhen me Pod-et e caktuar për të, **kube-proxy** programon networking-un që i bën IP-të virtuale të Service-it të routojnë te Pod-et e duhura, dhe një **container runtime** (containerd, CRI-O) faktikisht drejton container-at. Të shohësh si rrjedh një `kubectl apply` i vetëm nëpër këtë sistem — apiserver te etcd, controller-a që krijojnë object-e, scheduler që vendos Pod-e, kubelet që nis container-a, kube-proxy që lidh networking-un, të gjitha si watch-and-reconcile loop — zbulon dizajnin elegant, konsistent pas platformës. Ky model mendor është pikërisht ajo që të duhet për të debug-uar pse një Pod ka ngecur Pending (scheduler), pse cluster-i nuk përgjigjet (apiserver/etcd), ose pse një Service nuk po routon (kube-proxy), duke e bërë të domosdoshëm për të operuar dhe zgjidhur probleme në cluster-a realë.

Pamja e madhe

Komponentët e control plane

Komponentët e worker node

Si rrjedh një "kubectl apply" nëpër sistem

Pse ka rëndësi

Pyetje të ngjashme