# Kubernetes Sollicitatiegesprek: Pods, Services en Deployments Uitgelegd

> De drie fundamentele Kubernetes-bouwstenen — Pods, Services en Deployments — met productie-YAML, netwerk-internals en veelgestelde interviewvragen.

- Published: 2026-04-04
- Updated: 2026-04-04
- Author: SharpSkill
- Tags: kubernetes, devops, interview, containers, orchestration
- Reading time: 5 min

---

Kubernetes vormt de ruggengraat van moderne containerorkestratie en is een vast onderdeel geworden van technische sollicitatiegesprekken voor DevOps-, platform- en backend-engineers. De drie kernbouwstenen — Pods, Services en Deployments — vormen de basis van vrijwel elke Kubernetes-architectuur. Het verschil tussen kandidaten die definities opdreunen en kandidaten die productiesystemen kunnen ontwerpen, zit in het begrip van hoe deze objecten samenwerken.

Dit artikel behandelt elke primitief met productierijpe YAML-configuraties, legt de technische details uit waar interviewers naar vragen en behandelt de meest voorkomende vragen uit DevOps- en platform-engineering-interviews.

> **Snelle Referentie**
>
> Een Pod draait een of meer containers op een enkele node. Een Deployment beheert Pod-replica's en rollouts. Een Service biedt een stabiel netwerk-endpoint om die Pods te bereiken. Deze drie objecten dekken 80% van het workload management in elk Kubernetes-cluster vanaf versie v1.35.

## Kubernetes Pods begrijpen: De kleinste deploybare eenheid

Een Pod is de atomaire scheduling-eenheid in Kubernetes. Het bevat een of meer containers die dezelfde netwerk-namespace, IPC-namespace en storage-volumes delen. Elke container binnen een Pod krijgt hetzelfde IP-adres en kan met andere containers communiceren via `localhost`.

Het single-container Pod-patroon komt het meest voor. Multi-container Pods bestaan voor sidecar-scenario's — log collectors, service meshes of init containers die het bestandssysteem voorbereiden voordat het hoofdproces start.

```yaml
# api-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: api-server
  labels:
    app: api
    version: v2
spec:
  containers:
    - name: api
      image: registry.example.com/api:3.1.0
      ports:
        - containerPort: 8080
      resources:
        requests:
          cpu: "250m"        # 0.25 CPU core reserved
          memory: "256Mi"    # 256 MB reserved
        limits:
          cpu: "500m"        # hard cap at 0.5 core
          memory: "512Mi"    # OOMKilled beyond this
      readinessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 20
```

Het `resources`-blok is cruciaal in interviews. `requests` bepalen de scheduling — de scheduler plaatst de Pod op een node met voldoende beschikbare capaciteit. `limits` handhaven runtime-plafonds — overschrijding van het geheugenlimiet veroorzaakt een OOMKill, terwijl overschrijding van het CPU-limiet tot throttling leidt.

> **Veelgemaakte Interviewfout**
>
> Geheugenlimits instellen zonder requests veroorzaakt onvoorspelbare scheduling. Het kubelet kan de Pod plaatsen op een node die de workload niet daadwerkelijk kan dragen. Stel voor productie-Pods altijd zowel `requests` als `limits` in.

## Pod Lifecycle Fases en Restart Policies

Kubernetes volgt elke Pod door vijf fases: `Pending`, `Running`, `Succeeded`, `Failed` en `Unknown`. Interviewers vragen vaak wat elke overgang triggert.

| Fase | Betekenis | Veelvoorkomende Oorzaak |
|------|-----------|------------------------|
| Pending | Gepland maar niet actief | Image pull, onvoldoende resources |
| Running | Minstens een container actief | Normale werking |
| Succeeded | Alle containers afgesloten met code 0 | Batch jobs, init containers |
| Failed | Minstens een container afgesloten met niet-nul code | Applicatiecrash, OOMKill |
| Unknown | Communicatie met node verloren | Netwerkpartitie, node-uitval |

Het `restartPolicy`-veld bepaalt wat er gebeurt nadat een container stopt. `Always` (de standaard voor Deployments) herstart ongeacht de exit code. `OnFailure` herstart alleen bij niet-nul exits — geschikt voor Jobs. `Never` laat de container gestopt — gebruikt voor eenmalige debug-Pods.

```yaml
# batch-job-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-migration
spec:
  restartPolicy: OnFailure   # restart only on crash
  containers:
    - name: migrate
      image: registry.example.com/migrate:1.0.0
      command: ["python", "migrate.py"]
      env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: connection-string
```

Het `valueFrom.secretKeyRef`-patroon houdt gevoelige gegevens buiten het manifest. Kubernetes Secrets zijn standaard base64-gecodeerd — niet versleuteld. Voor productie dient encryptie at rest ingeschakeld te worden via de `EncryptionConfiguration`-API of een externe secret manager zoals HashiCorp Vault.

## Kubernetes Deployments: Declaratieve Rollouts en Scaling

Een [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) maakt en beheert ReplicaSets, die op hun beurt Pods beheren. De Deployment-controller bewaakt de gewenste staat en brengt deze in overeenstemming met de werkelijkheid — Pods toevoegen bij opschaling, vervangen tijdens rollouts en terugdraaien wanneer health checks falen.

Directe Pod-creatie is vrijwel nooit gepast in productie. Deployments bieden replica-beheer, rolling updates, rollback-geschiedenis en pause/resume-mogelijkheden.

```yaml
# api-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api
spec:
  replicas: 3                    # run 3 identical Pods
  revisionHistoryLimit: 5        # keep 5 old ReplicaSets for rollback
  selector:
    matchLabels:
      app: api                   # must match Pod template labels
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1          # at most 1 Pod down during update
      maxSurge: 1                # at most 1 extra Pod during update
  template:
    metadata:
      labels:
        app: api
        version: v2
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
```

De `strategy.rollingUpdate`-sectie definieert het zero-downtime deployment-gedrag. Met `maxUnavailable: 1` en `maxSurge: 1` maakt Kubernetes een nieuwe Pod aan, wacht tot deze de readiness checks doorstaat en beëindigt dan een oude Pod. Deze cyclus herhaalt zich totdat alle replica's de nieuwe versie draaien.

### Een Mislukt Kubernetes Deployment Terugdraaien

Rollbacks zijn een veelvoorkomend interviewonderwerp. De Deployment-controller bewaart oude ReplicaSets (beheerst door `revisionHistoryLimit`) zodat terugdraaien instant gaat — geen image rebuild nodig.

```bash
# Check rollout status
kubectl rollout status deployment/api-server

# View revision history
kubectl rollout history deployment/api-server

# Roll back to previous version
kubectl rollout undo deployment/api-server

# Roll back to specific revision
kubectl rollout undo deployment/api-server --to-revision=3
```

Het `undo`-commando patcht de Deployment-spec om overeen te komen met het Pod-template van de doelrevisie. De rolling update-strategie wordt vervolgens normaal toegepast, waarbij huidige Pods geleidelijk worden vervangen door de rollback-versie.

## Kubernetes Services: Stabiel Netwerk voor Dynamische Pods

Pods zijn vluchtig. Ze krijgen bij elke herstart nieuwe IP-adressen. Een [Service](https://kubernetes.io/docs/concepts/services-networking/service/) lost dit op door een stabiel virtueel IP (ClusterIP) en een DNS-naam te bieden die verkeer routeert naar gezonde Pods die overeenkomen met een label selector.

De kube-proxy-component op elke node programmeert iptables- of IPVS-regels om verkeer te verdelen over backend-Pods. Wanneer een Pod zijn readiness probe niet haalt, verwijdert de Endpoints-controller deze uit de Service — geen verkeer bereikt ongezonde instanties.

```yaml
# api-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP               # internal-only by default
  selector:
    app: api                     # routes to Pods with this label
  ports:
    - name: http
      port: 80                   # Service port (what clients use)
      targetPort: 8080           # Pod port (where container listens)
      protocol: TCP
```

Na aanmaak kan elke Pod in het cluster deze Service bereiken op `api-service.default.svc.cluster.local` (of gewoon `api-service` binnen dezelfde namespace). CoreDNS verzorgt de resolutie.

## Service Types: ClusterIP, NodePort en LoadBalancer

Interviewers verwachten dat kandidaten de drie belangrijkste Service-typen kunnen uitleggen en wanneer elk van toepassing is.

| Type | Toegangsbereik | Gebruikssituatie |
|------|----------------|------------------|
| ClusterIP | Alleen cluster-intern | Backend API's, databases, caches |
| NodePort | Extern via `<NodeIP>:<Port>` | Development, bare-metal clusters |
| LoadBalancer | Extern via cloud LB | Productieverkeer op AWS/GCP/Azure |

```yaml
# api-loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
  name: api-public
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"  # AWS NLB
spec:
  type: LoadBalancer
  selector:
    app: api
  ports:
    - name: https
      port: 443
      targetPort: 8080
      protocol: TCP
```

Het `LoadBalancer`-type triggert de load balancer-controller van de cloud provider om een extern endpoint te provisioneren. Op AWS creëert dit een NLB of ALB afhankelijk van de annotations. Op bare-metal clusters zonder cloud-integratie vervullen MetalLB of kube-vip deze rol.

> **Gateway API Vervangt Ingress**
>
> Sinds Kubernetes v1.35 is de Ingress NGINX-controller officieel uitgefaseerd. De [Gateway API](https://gateway-api.sigs.k8s.io/) is nu de aanbevolen aanpak voor HTTP-routing, TLS-terminatie en traffic splitting. Nieuwe clusters dienen Gateway API vanaf het begin te adopteren.

## Deployments en Services Verbinden met Label Selectors

De koppeling tussen een Deployment en een Service is de label selector — meer niet. Er bestaat geen explicite verwijzing tussen de twee objecten. De Service bewaakt Pods waarvan de labels overeenkomen met zijn `spec.selector` en onderhoudt automatisch een Endpoints-lijst.

Deze ontkoppelde architectuur betekent dat een enkele Service verkeer kan routeren naar Pods van meerdere Deployments (handig voor canary releases), en een Deployment kan worden blootgesteld door meerdere Services (verschillende poorten, verschillende toegangsniveaus).

```yaml
# canary-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: api                   # same label as main Deployment
  template:
    metadata:
      labels:
        app: api                 # Service picks this up automatically
        version: v3-canary
    spec:
      containers:
        - name: api
          image: registry.example.com/api:3.2.0-rc1
          ports:
            - containerPort: 8080
```

Met het hoofd-Deployment op 3 replica's en het canary op 1, verdeelt de Service ongeveer 25% van het verkeer naar de canary. Geen Service-configuratiewijziging nodig — label matching regelt alles.

## Horizontal Pod Autoscaling voor Kubernetes Deployments

Statische replica-aantallen verspillen resources bij laag verkeer en bezwijken onder pieken. De [HorizontalPodAutoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) past het replica-aantal aan op basis van waargenomen metrics.

```yaml
# api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # scale up above 70% CPU
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # wait 5 min before scaling down
```

De HPA bevraagt de metrics server standaard elke 15 seconden. Kubernetes v1.35 introduceerde configureerbare HPA-tolerantie, ter vervanging van de hardgecodeerde drempel van 10%. Dit betekent dat teams met latentiegevoelige workloads nu nauwkeurigere scaling-triggers kunnen instellen.

De `behavior.scaleDown.stabilizationWindowSeconds`-parameter voorkomt flapping — snelle scale-up/scale-down-cycli veroorzaakt door grillig verkeerspatronen.

## Veelgestelde Kubernetes Interviewvragen met Antwoorden

Deze vragen komen herhaaldelijk voor in DevOps- en platform-engineering-interviews. Elk antwoord richt zich op de diepgang die interviewers verwachten.

**Wat gebeurt er wanneer een Pod zijn geheugenlimiet overschrijdt?**
Het kubelet stuurt een SIGKILL via de OOM killer. De container stopt met code 137. De Deployment-controller detecteert de gefaalde Pod en maakt een vervanging aan, afhankelijk van het restart-beleid en eventuele backoff-vertragingen.

**Hoe routeert Kubernetes verkeer naar een specifieke Pod-versie tijdens canary releases?**
De Service-selector matcht op gedeelde labels (bijv. `app: api`). Zowel het stabiele als het canary Deployment gebruiken dit label. Verkeerverdeling is proportioneel aan het aantal ready endpoints — 3 stabiele replica's + 1 canary replica betekent ~25% canary verkeer. Voor precies traffic splitting (bijv. 5%), gebruik Gateway API HTTPRoute met gewogen backends.

**Wat is het verschil tussen `readinessProbe` en `livenessProbe`?**
Een readiness probe bepaalt of de Pod verkeer ontvangt van de Service. Een falende readiness probe verwijdert de Pod uit de Endpoints-lijst maar herstart deze niet. Een liveness probe bepaalt of de container wordt herstart. Een falende liveness probe triggert een container-herstart. Beide kunnen HTTP-, TCP- of exec-checks gebruiken.

**Hoe garanderen rolling updates zero downtime?**
De Deployment-controller maakt nieuwe Pods aan voordat oude worden beëindigd, beheerst door `maxSurge` en `maxUnavailable`. Nieuwe Pods moeten readiness probes doorstaan voordat oude Pods worden gedraineerd. De `terminationGracePeriodSeconds` (standaard: 30s) geeft lopende verzoeken tijd om af te ronden voordat SIGKILL wordt verstuurd.

Voorbereiding op een Kubernetes-interview vereist praktische YAML-ervaring, niet alleen theorie. De [DevOps interviewvragen](/technologies/devops/interview-questions/kubernetes-basics) op SharpSkill behandelen deze onderwerpen met interactieve oefeningen.

## Conclusie

- Pods zijn de scheduling-eenheid — stel altijd resource `requests` en `limits` in, en configureer zowel readiness als liveness probes
- Deployments beheren replica-aantallen, rolling updates en rollback-geschiedenis via ReplicaSets — maak nooit losse Pods in productie
- Services bieden stabiel netwerk via label selectors en virtuele IP's — ClusterIP voor intern verkeer, LoadBalancer voor extern
- De koppeling tussen Deployments en Services is puur label-gebaseerd, wat canary-patronen mogelijk maakt zonder configuratiewijzigingen
- HPA schaalt Deployments op basis van CPU/geheugen-metrics — gebruik `stabilizationWindowSeconds` om flapping te voorkomen
- Gateway API vervangt Ingress NGINX sinds Kubernetes v1.35 — nieuwe projecten dienen het vanaf het begin te adopteren
- Oefen met echte YAML-manifesten en `kubectl`-commando's in plaats van definities te memoriseren

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/nl/blog/devops/kubernetes-interview-pods-services-deployments-explained