Descrie arhitectura Kubernetes: control plane vs worker nodes și componentele lor.

Question

IT Interview Practice · Accepted Answer

Un cluster Kubernetes are două tipuri de mașini: **control plane** (creierul care ia decizii și stochează starea) și **worker nodes** (unde rulează efectiv Pod-urile tale). Fiecare are un set restrâns de componente bine definite.

## Imaginea de ansamblu

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

## Componentele control plane

```text
kube-apiserver        Singurul punct de intrare. Expune API-ul REST; validează &
                      persistă obiectele în etcd. kubectl, controllerele și kubelet-urile
                      vorbesc DOAR cu apiserver-ul.
etcd                  Key-value store distribuit, consistent. Deține ÎNTREAGA
                      stare a clusterului (dorită + curentă). Pierzi etcd = pierzi clusterul.
kube-scheduler        Urmărește Pod-urile fără node asignat și alege cel mai bun node
                      (pe baza cererilor de resurse, affinity, taints etc.).
kube-controller-      Rulează buclele de control: node controller, replication (ReplicaSet),
manager               deployment, job, endpoints etc. Fiecare buclă duce actual → dorit.
cloud-controller-     (Pe cloud) se integrează cu providerul: load balancers, rute,
manager               ciclul de viață al node-urilor.
```

## Componentele unui worker node

```text
kubelet          Agentul node-ului. Vorbește cu apiserver-ul, pornește/oprește containere prin
                 runtime și raportează statusul Pod-urilor & al node-ului. Face realitatea
                 node-ului să corespundă Pod-urilor asignate lui.
kube-proxy       Programează networking-ul node-ului (iptables/IPVS) astfel încât IP-urile virtuale
                 de Service să fie load-balansate spre endpoint-urile Pod corecte.
container runtime Software-ul care rulează efectiv containerele (containerd, CRI-O).
```

## Cum curge un "kubectl apply" prin sistem

```text
1. kubectl → kube-apiserver: "Vreau un Deployment cu 3 replici"
2. apiserver validează & scrie obiectul în etcd
3. controller-manager (deployment→replicaset controller) îl vede, creează 3 obiecte Pod
4. scheduler vede 3 Pod-uri neasignate, asignează fiecare unui node (scrie înapoi prin apiserver)
5. kubelet-ul fiecărui node își vede Pod-urile, spune runtime-ului să tragă imaginile & pornească containerele
6. kube-proxy conectează networking-ul de Service ca traficul să ajungă la noile Pod-uri
Totul este o buclă WATCH + RECONCILE mediată de apiserver.
```

```bash
kubectl get nodes                 # listează node-urile (control-plane + workers)
kubectl get pods -n kube-system   # vezi componentele control-plane / de sistem
kubectl get componentstatuses     # sănătatea pieselor de bază ale control-plane
```

## De ce contează

Înțelegerea împărțirii dintre control plane și worker nodes — și a rolului fiecărei componente — este ceea ce transformă Kubernetes dintr-o cutie neagră într-un sistem despre care poți raționa și pe care îl poți opera, așa că este cunoaștere de bază pentru orice inginer de nivel middle sau mai sus. **Control plane** este creierul care ia deciziile: **kube-apiserver** este singura ușă de intrare prin care comunică fiecare componentă și utilizator; **etcd** este key-value store-ul consistent care deține întreaga stare a clusterului și este sursa de adevăr (pierderea lui înseamnă pierderea clusterului); **scheduler-ul** decide pe care node aterizează fiecare Pod nou; iar **controller-manager** rulează buclele de reconciliere care conduc continuu starea reală spre cea dorită. Pe fiecare **worker node**, **kubelet** este agentul care face containerele node-ului să corespundă Pod-urilor asignate lui, **kube-proxy** programează networking-ul care face IP-urile virtuale de Service să ruteze spre Pod-urile corecte, iar un **container runtime** (containerd, CRI-O) rulează efectiv containerele. Observând cum curge un singur `kubectl apply` prin acest sistem — apiserver spre etcd, controllere creând obiecte, scheduler plasând Pod-uri, kubelet-uri pornind containere, kube-proxy conectând networking-ul, toate ca bucle de watch-and-reconcile — se dezvăluie designul elegant și consistent din spatele platformei. Acest model mental este exact ce îți trebuie pentru a depana de ce un Pod rămâne blocat în Pending (scheduler), de ce clusterul nu răspunde (apiserver/etcd) sau de ce un Service nu rutează (kube-proxy), făcându-l indispensabil pentru operarea și depanarea clusterelor reale.

Imaginea de ansamblu

Componentele control plane

Componentele unui worker node

Cum curge un "kubectl apply" prin sistem

De ce contează

Întrebări conexe