Vad är en Pod och varför är den den minsta driftsättbara enheten i Kubernetes?

Question

IT Interview Practice · Accepted Answer

En **Pod** är den minsta driftsättbara enheten i Kubernetes: ett omslag runt **en eller flera containrar** som delar samma network namespace (en IP) och kan dela storage-volymer. Du driftsätter inte containrar direkt — du driftsätter Pods.

## Vad som finns inuti en 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            │
└────────────────────────────────────────────────────────────┘
```

Containrar i samma Pod är **alltid samlokaliserade (co-located)** på samma nod, schemaläggs tillsammans och kan nå varandra över `localhost`.

## En minimal Pod

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

## Varför en Pod, och inte bara en 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.
```

## Pods är efemära — hantera dem inte direkt

```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          # se Pods, deras nod och IP
kubectl describe pod web          # händelser, status, omstarter
kubectl logs web -c web           # loggar för en specifik container
kubectl exec -it web -- sh        # öppna en shell i containern
```

## Varför det är viktigt

Pod:en är Kubernetes grundläggande byggsten, så att förstå vad den är och varför den finns är väsentlig, oumbärlig kunskap. Kubernetes schemalägger inte nakna containrar; det schemalägger **Pods** — ett tunt omslag runt en eller flera containrar som delar ett network namespace (en enda IP, nåbar sinsemellan över `localhost`) och kan dela storage-volymer. Att förstå att containrar i en Pod **alltid är samlokaliserade och samschemalagda** på en nod förklarar vad en Pod är *till för*: att gruppera containrar som måste köra tillsammans och dela resurser, såsom en huvudapplikation plus en tätt kopplad **sidecar** (en log shipper, proxy eller adapter) — samtidigt som man inser att de flesta Pods i praktiken bara innehåller en enda container. Lika viktigt är att förstå att Pods är **efemära och engångs**: de får en ny IP vid varje återskapande och återuppstår inte på egen hand om en nod dör, vilket är precis därför du sällan skapar nakna Pods och istället förlitar dig på controllers på högre nivå (**Deployments**, **StatefulSets**, **Jobs**) som skapar och ersätter Pods för att upprätthålla ett önskat tillstånd. Denna distinktion — Pod:en som den atomära enheten, hanterad av controllers snarare än för hand — är den begreppsmässiga bryggan från enskilda containrar till riktiga Kubernetes-workloads, och vardagskunskap för alla som driftsätter, felsöker (via `kubectl logs`, `describe`, `exec`) eller resonerar om applikationer på ett kluster.

Vad som finns inuti en Pod

En minimal Pod

Varför en Pod, och inte bara en container?

Pods är efemära — hantera dem inte direkt

Varför det är viktigt

Relaterade frågor