Che cos'è un Pod e perché è l'unità distribuibile più piccola in Kubernetes?

Question

IT Interview Practice · Accepted Answer

Un **Pod** è l'unità distribuibile più piccola in Kubernetes: un involucro attorno a **uno o più container** che condividono lo stesso network namespace (un unico IP) e possono condividere volumi di storage. Non distribuisci direttamente i container — distribuisci i Pod.

## Cosa c'è dentro un Pod

```text
┌───────────────── Pod (has ONE shared IP) ─────────────────┐
│                                                            │
│   ┌──────────────┐   ┌──────────────┐   shared:           │
│   │  container A  │   │  container B  │    • network (IP)   │
│   │  (app)        │   │  (sidecar)    │    • localhost      │
│   └──────────────┘   └──────────────┘    • volumes         │
│         │ talk to each other via localhost:port            │
└────────────────────────────────────────────────────────────┘
```

I container nello stesso Pod sono **sempre co-locati (co-located)** sullo stesso node, schedulati insieme, e possono raggiungersi a vicenda su `localhost`.

## Un Pod minimale

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: web
  labels: { app: web }
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80
```

## Perché un Pod e non solo un container?

```text
The Pod is an abstraction that lets a "logical application" be more than one
container that MUST run together and share resources:
  → a main app container + a helper "sidecar" (log shipper, proxy, etc.)
  → they share the same IP and can use shared volumes for exchanging files
Most Pods hold a SINGLE container. Multi-container Pods are for tight coupling only.
```

## I Pod sono effimeri — non gestirli direttamente

```text
A Pod is DISPOSABLE:
  → it gets a new IP each time it is (re)created
  → if the node dies, the Pod is GONE (not rescheduled by itself)
→ You almost never create bare Pods in production.
→ Instead a controller (Deployment / StatefulSet / Job) creates and REPLACES
  Pods for you, keeping the desired count alive.
```

```bash
kubectl get pods -o wide          # see Pods, their node and IP
kubectl describe pod web          # events, status, restarts
kubectl logs web -c web           # logs of a specific container
kubectl exec -it web -- sh        # shell into the container
```

## Perché è importante

Il Pod è il mattone fondamentale di Kubernetes, quindi capire che cos'è e perché esiste è una conoscenza essenziale, da conoscere assolutamente. Kubernetes non schedula container nudi; schedula **Pod** — un involucro sottile attorno a uno o più container che condividono un network namespace (un unico IP, raggiungibili tra loro su `localhost`) e possono condividere volumi di storage. Capire che i container di un Pod sono **sempre co-locati e co-schedulati** su un solo node spiega a *cosa serve* un Pod: raggruppare container che devono girare insieme e condividere risorse, come un'applicazione principale più un **sidecar** strettamente accoppiato (un log shipper, un proxy o un adapter) — pur riconoscendo che nella pratica la maggior parte dei Pod contiene un solo container. Altrettanto importante è cogliere che i Pod sono **effimeri e usa-e-getta**: ottengono un nuovo IP a ogni ricreazione e non risorgono da soli se un node muore, ed è esattamente per questo che raramente crei Pod nudi e ti affidi invece a controller di livello superiore (**Deployment**, **StatefulSet**, **Job**) che creano e sostituiscono i Pod per mantenere uno stato desiderato. Questa distinzione — il Pod come unità atomica, gestita dai controller anziché a mano — è il ponte concettuale dai singoli container ai veri workload di Kubernetes, e una conoscenza quotidiana per chiunque distribuisca, faccia debug (tramite `kubectl logs`, `describe`, `exec`) o ragioni sulle applicazioni in un cluster.

Cosa c'è dentro un Pod

Un Pod minimale

Perché un Pod e non solo un container?

I Pod sono effimeri — non gestirli direttamente

Perché è importante

Domande correlate