Descrivi l'architettura di Kubernetes: control plane vs worker node e i loro componenti.

Question

IT Interview Practice · Accepted Answer

Un cluster Kubernetes ha due tipi di macchine: il **control plane** (il "cervello" che prende le decisioni e conserva lo stato) e i **worker node** (dove i tuoi Pod girano effettivamente). Ciascuno ha un piccolo insieme di componenti ben definiti.

## Il quadro generale

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

## Componenti del 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.
```

## Componenti del 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).
```

## Come un "kubectl apply" attraversa il 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                 # list nodes (control-plane + workers)
kubectl get pods -n kube-system   # see the control-plane / system components
kubectl get componentstatuses     # health of core control-plane pieces
```

## Perché è importante

Capire la separazione tra control plane e worker node — e il ruolo di ciascun componente — è ciò che trasforma Kubernetes da scatola nera a sistema su cui puoi ragionare e che puoi operare, quindi è conoscenza di base per qualsiasi ingegnere di livello middle o superiore. Il **control plane** è il cervello decisionale: il **kube-apiserver** è l'unica porta d'ingresso attraverso cui ogni componente e utente comunica; **etcd** è il key-value store consistente che conserva l'intero stato del cluster ed è la fonte di verità (perderlo significa perdere il cluster); lo **scheduler** decide su quale node atterra ogni nuovo Pod; e il **controller-manager** esegue i reconciliation loop che spingono di continuo lo stato reale verso quello desiderato. Su ogni **worker node**, il **kubelet** è l'agent che fa corrispondere i container del node ai Pod a esso assegnati, **kube-proxy** programma il networking che fa instradare gli IP virtuali dei Service ai Pod giusti, e un **container runtime** (containerd, CRI-O) esegue effettivamente i container. Vedere come un singolo `kubectl apply` attraversa questo sistema — apiserver verso etcd, i controller che creano oggetti, lo scheduler che colloca i Pod, i kubelet che avviano i container, kube-proxy che collega il networking, tutto come watch-and-reconcile loop — rivela il design elegante e coerente dietro la piattaforma. Questo modello mentale è esattamente ciò che ti serve per fare debug del perché un Pod resti bloccato in Pending (scheduler), del perché il cluster non risponda (apiserver/etcd) o del perché un Service non instradi (kube-proxy), rendendolo indispensabile per operare e risolvere i problemi di cluster reali.

Il quadro generale

Componenti del control plane

Componenti del worker node

Come un "kubectl apply" attraversa il sistema

Perché è importante

Domande correlate