Pod in Kubernetes: de kleinste eenheid die je cluster draaiende houdt

Je kunt geen Deployment, Service of StatefulSet doorgronden zonder eerst te snappen wat een pod is. Alles wat Kubernetes orkestreert, wordt uiteindelijk uitgedrukt in pods. Toch is de pod zelf geen container — het is een logische groep containers die samen op één node draaien en hetzelfde netwerk, dezelfde opslag en dezelfde IP delen.

Die gedeelde context is precies waarom pods bestaan. Containers zijn geïsoleerde processen; pods zijn de lijm die ze samenbrengt wanneer ze elkaar nodig hebben.

Vereisten

• Een werkend Kubernetes-cluster, versie 1.28 of hoger. Minikube of kind volstaat voor lokaal testen.
• `kubectl` geïnstalleerd, versie binnen één minor van je cluster.
• Toegang tot een namespace waar je pods mag aanmaken.
• Een actieve `kubeconfig` die naar dat cluster wijst.

Controleer eerst je verbinding:

```bash kubectl version --client kubectl cluster-info ```

Als `cluster-info` een adres teruggeeft, ben je verbonden. Krijg je een foutmelding over een ontbrekende context, dan is je `kubeconfig` niet geladen en heeft elke volgende stap geen zin.

Stappen

1. Begrijp wat een pod onderscheidt van een container

Een container is een isolatie-eenheid. Een pod is een plannings- en netwerkeenheid. Dat verschil bepaalt alles wat volgt.

Containers binnen één pod delen dezelfde netwerknamespace. Ze zien elkaars poorten via `localhost`, want ze gebruiken dezelfde loopback-interface. Ze kunnen ook dezelfde volumes mounten. Twee containers in aparte pods kunnen dat niet zonder een Service ertussen.

De praktische consequentie: wil je dat twee processen via `localhost` praten, zet ze dan in één pod. Wil je dat ze onafhankelijk schalen, zet ze in aparte pods.

2. Schrijf een minimaal pod-manifest

Je definieert een pod declaratief in YAML. Dat is geen formaliteit — een manifest is versiebeheerbaar, herhaalbaar en reviewbaar.

Maak een bestand `nginx-pod.yaml`:

```yaml apiVersion: v1 kind: Pod metadata: name: nginx-pod labels: app: nginx spec: containers:

• name: nginx

image: nginx:1.27 ports: - containerPort: 80 ```

Let op de tag `nginx:1.27` in plaats van `latest`. Een expliciete versie zorgt dat je pod morgen nog hetzelfde draait als vandaag. Met `latest` verandert je image onder je voeten zonder dat je manifest iets zegt.

3. Pas het manifest toe

Nu laat je Kubernetes de pod aanmaken:

```bash kubectl apply -f nginx-pod.yaml ```

De `kube-scheduler` kiest een node op basis van beschikbare resources, affiniteitsregels en taints. Je hebt op dit punt nog geen invloed op welke node het wordt — dat is precies de bedoeling. Laat de scheduler zijn werk doen tenzij je een echte reden hebt om een pod aan een specifieke node te binden.

4. Bekijk de status van de pod

Een pod doorloopt vaste fasen: `Pending`, `Running`, `Succeeded`, `Failed` en `Unknown`. Je wilt `Running` zien.

```bash kubectl get pod nginx-pod -o wide ```

De `-o wide` geeft je ook de node en het IP. Blijft de status op `Pending` hangen, dan kon de scheduler geen geschikte node vinden — meestal door onvoldoende resources of een taint die niet getolereerd wordt.

5. Lees de details als er iets misgaat

Bij een `Pending`, `CrashLoopBackOff` of `ImagePullBackOff` wil je de events zien. Die staan onderaan de describe-output.

```bash kubectl describe pod nginx-pod ```

De sectie `Events` vertelt je wat Kubernetes probeerde en waar het stopte. Een `ImagePullBackOff` betekent bijna altijd een verkeerde image-tag of een ontbrekende pull-secret. Een `CrashLoopBackOff` betekent dat de container start en direct weer stopt — dan zit het probleem in je applicatie, niet in je manifest.

6. Open een shell in de container

Voor debuggen wil je soms gewoon in de container kijken:

```bash kubectl exec -it nginx-pod -- /bin/sh ```

Dit opent een shell in de `nginx`-container. Draait je pod meerdere containers, dan moet je de containernaam meegeven met `-c`:

```bash kubectl exec -it nginx-pod -c nginx -- /bin/sh ```

Zonder `-c` pakt `kubectl` de eerste container in de pod. Dat is meestal goed, maar niet altijd.

7. Bekijk de logs

Logs zijn je eerste aanknopingspunt bij een container die niet doet wat je verwacht:

```bash kubectl logs nginx-pod ```

Wil je live meelezen, voeg dan `-f` toe. Bij een pod met meerdere containers geef je opnieuw de containernaam mee:

```bash kubectl logs -f nginx-pod -c nginx ```

Logs verdwijnen zodra de pod weg is. Wil je ze bewaren, dan moet je ze naar buiten sturen — naar een logcollector of een `DaemonSet` zoals Fluent Bit. Kubernetes bewaart ze niet voor je.

8. Ruim de pod op

Een losse pod heeft geen controller die hem herstelt. Verwijder je hem, dan is hij weg:

```bash kubectl delete pod nginx-pod ```

Dit is meteen het belangrijkste argument om in de praktijk geen losse pods te draaien. Een `Deployment` maakt een `ReplicaSet` die pods beheert en vervangt als ze omvallen. Een pod die je met de hand aanmaakt, heeft dat vangnet niet.

Verificatie

Controleer of je pod draait en of de container daadwerkelijk luistert:

```bash kubectl get pod nginx-pod -o jsonpath='{.status.phase}' ```

Je wilt `Running` terugkrijgen. Wil je ook het IP en de node zien:

```bash kubectl get pod nginx-pod -o wide ```

Test vervolgens of de container bereikbaar is van binnenuit het cluster:

```bash kubectl run curl-test --image=curlimages/curl:8.10.1 --restart=Never --rm -it -- curl -s http://$(kubectl get pod nginx-pod -o jsonpath='{.status.podIP}') ```

Krijg je HTML van de Nginx-welkomstpagina terug, dan werkt de pod en is het netwerk correct. Een time-out betekent dat de container niet luistert of dat een NetworkPolicy het verkeer blokkeert.

Veelgestelde problemen

Pod blijft op `Pending`. De scheduler vindt geen node met genoeg resources. Controleer met `kubectl describe pod nginx-pod` de events onderaan. Vraagt je pod meer CPU of geheugen dan elke node heeft, dan blijft hij eeuwig wachten. Verlaag de requests in je manifest of voeg een node toe.

`ImagePullBackOff` of `ErrImagePull`. De image-tag bestaat niet, of je cluster heeft geen toegang tot de registry. Test de tag lokaal met `docker pull nginx:1.27`. Werkt dat wel, dan mist je cluster een `imagePullSecret` voor een private registry.

`CrashLoopBackOff`. De container start en stopt direct. Bekijk de vorige run met `kubectl logs nginx-pod --previous`. Vaak is het een verkeerd commando, een ontbrekende environment variable of een applicatiefout die pas zichtbaar wordt bij het opstarten.

Waarom pods vluchtig zijn

Pods zijn ontworpen om te verdwijnen. Een `Deployment` schaalt, rolt updates uit en herstelt fouten door pods te vernietigen en opnieuw te maken. Dat betekent dat je applicatie stateless moet zijn, of dat persistente data in een `PersistentVolume` hoort dat losstaat van de pod.

Elke pod krijgt een eigen IP, maar dat IP verandert zodra de pod opnieuw wordt gemaakt. Daarom verbind je nooit rechtstreeks met een pod-IP in productie. Een `Service` geeft je een stabiel eindpunt dat aanvragen doorstuurt naar de groep pods erachter, ongeacht hoeveel er op dat moment draaien.

Voor services die op elke node moeten staan — logcollectie, monitoring agents — gebruik je een `DaemonSet`. Die garandeert precies één exemplaar per node. Een `StatefulSet` gebruik je wanneer pods een stabiele identiteit en eigen opslag nodig hebben, zoals bij databases.

De pod is het niveau waarop je al deze keuzes maakt. Wie de pod begrijpt, begrijpt waarom de rest van Kubernetes er zo uitziet als het doet.