Iddeskrivi l-arkitettura ta' Kubernetes: control plane vs worker nodes u l-komponenti tagħhom.

Question

IT Interview Practice · Accepted Answer

Cluster ta' Kubernetes għandu żewġ tipi ta' magni: il-**control plane** (il-"moħħ" li jieħu d-deċiżjonijiet u jaħżen l-istat) u l-**worker nodes** (fejn tabilħaqq jaħdmu l-Pods tiegħek). Kull wieħed għandu sett żgħir ta' komponenti definiti sew.

## Il-kwadru ġenerali

```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) │
└─────────────────────┘ └─────────────────────┘
```

## Komponenti tal-control plane

```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.
```

## Komponenti tal-worker node

```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).
```

## Kif "kubectl apply" jgħaddi mis-sistema

```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                 # elenka n-nodes (control-plane + workers)
kubectl get pods -n kube-system   # ara l-komponenti tal-control-plane / sistema
kubectl get componentstatuses     # is-saħħa tal-biċċiet ewlenin tal-control-plane
```

## Għaliex huwa importanti

Li tifhem il-firda bejn il-control plane u l-worker nodes — u r-rwol ta' kull komponent — huwa dak li jibdel Kubernetes minn black box għal sistema li tista' tirraġuna dwarha u topera, għalhekk huwa għarfien ewlieni għal kull inġinier tal-livell middle jew ogħla. Il-**control plane** huwa l-moħħ li jieħu d-deċiżjonijiet: il-**kube-apiserver** huwa l-bieb ta' quddiem wieħed li permezzu jikkomunika kull komponent u utent; **etcd** huwa l-key-value store konsistenti li jżomm l-istat sħiħ tal-cluster u huwa s-sors tal-verità (li titilfu jfisser li titlef il-cluster); l-**scheduler** jiddeċiedi fuq liema node jinżel kull Pod ġdid; u l-**controller-manager** iħaddem il-loops ta' rikonċiljazzjoni li kontinwament imexxu l-istat attwali lejn l-istat mixtieq. Fuq kull **worker node**, il-**kubelet** huwa l-aġent li jagħmel il-containers tan-node jaqblu mal-Pods assenjati lilu, **kube-proxy** jipprogramma n-networking li jagħmel l-IPs virtwali tas-Service jirrawtjaw għall-Pods it-tajba, u **container runtime** (containerd, CRI-O) tabilħaqq iħaddem il-containers. Li tara kif `kubectl apply` wieħed jgħaddi minn din is-sistema — apiserver għal etcd, controllers li joħolqu objects, scheduler li jqiegħed il-Pods, kubelets li jibdew il-containers, kube-proxy li jgħaqqad in-networking, kollha bħala watch-and-reconcile loops — jikxef id-disinn eleganti u konsistenti wara l-pjattaforma. Dan il-mudell mentali huwa eżatt dak li teħtieġ biex tiddibaggja għaliex Pod huwa mwaħħal Pending (scheduler), għaliex il-cluster ma jweġibx (apiserver/etcd), jew għaliex Service ma jirrawtjax (kube-proxy), u jagħmlu indispensabbli biex topera u ssolvi l-problemi ta' clusters reali.

Il-kwadru ġenerali

Komponenti tal-control plane

Komponenti tal-worker node

Kif "kubectl apply" jgħaddi mis-sistema

Għaliex huwa importanti

Mistoqsijiet relatati