Kubernetes Interview: Pods, Services und Deployments im Detail erklärt

Kubernetes-Interviews stellen Kandidaten immer wieder vor dieselben drei Kernkonzepte: Pods, Services und Deployments. Wer diese Bausteine nicht nur definieren, sondern auch ihre Zusammenhänge erklären kann — vom Container-Scheduling über das Netzwerk-Routing bis zu Rolling Updates — hebt sich deutlich von der Konkurrenz ab.

Dieser Leitfaden behandelt jede dieser Primitiven mit produktionsreifem YAML, erklärt die technischen Details, die Interviewer interessieren, und deckt die häufigsten Fragen aus DevOps- und Platform-Engineering-Interviews ab.

Kubernetes Pods verstehen: Die kleinste deploybare Einheit

Ein Pod ist die atomare Scheduling-Einheit in Kubernetes. Er kapselt einen oder mehrere Container, die sich denselben Netzwerk-Namespace, IPC-Namespace und Storage-Volumes teilen. Jeder Container innerhalb eines Pods erhält dieselbe IP-Adresse und kann mit benachbarten Containern über localhost kommunizieren.

Der Single-Container-Pod ist das häufigste Muster. Multi-Container-Pods existieren für Sidecar-Szenarien — Log-Collectoren, Service-Meshes oder Init-Container, die das Dateisystem vorbereiten, bevor der Hauptprozess startet.

# 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

Der resources-Block ist in Interviews entscheidend. requests bestimmen das Scheduling — der Scheduler platziert den Pod auf einem Node mit ausreichend verfügbarer Kapazität. limits erzwingen Obergrenzen zur Laufzeit — das Überschreiten des Speicherlimits löst einen OOMKill aus, während das Überschreiten des CPU-Limits zu Throttling führt.

Pod-Lebenszyklusphasen und Restart-Policies

Kubernetes verfolgt jeden Pod durch fünf Phasen: Pending, Running, Succeeded, Failed und Unknown. Interviewer fragen häufig, was jede Transition auslöst.

| Phase | Bedeutung | Häufige Ursache | |-------|-----------|----------------| | Pending | Geplant, aber nicht gestartet | Image-Pull, unzureichende Ressourcen | | Running | Mindestens ein Container aktiv | Normaler Betrieb | | Succeeded | Alle Container mit Exit-Code 0 beendet | Batch-Jobs, Init-Container | | Failed | Mindestens ein Container mit Exit-Code ungleich 0 | Anwendungsabsturz, OOMKill | | Unknown | Node-Kommunikation unterbrochen | Netzwerkpartition, Node-Ausfall |

Das Feld restartPolicy steuert das Verhalten nach dem Beenden eines Containers. Always (Standard für Deployments) startet unabhängig vom Exit-Code neu. OnFailure startet nur bei Exit-Codes ungleich 0 neu — nützlich für Jobs. Never lässt den Container beendet — verwendet für einmalige Debug-Pods.

# 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

Das Pattern valueFrom.secretKeyRef hält sensitive Daten aus dem Manifest heraus. Kubernetes Secrets sind standardmäßig nur Base64-kodiert — nicht verschlüsselt. Für den Produktionseinsatz sollte die Verschlüsselung at rest über die EncryptionConfiguration-API aktiviert oder ein externer Secret-Manager wie HashiCorp Vault verwendet werden.

Kubernetes Deployments: Deklarative Rollouts und Skalierung

Ein Deployment erstellt und verwaltet ReplicaSets, die wiederum Pods verwalten. Der Deployment-Controller überwacht den gewünschten Zustand und gleicht ihn mit der Realität ab — er fügt Pods beim Hochskalieren hinzu, ersetzt sie während Rollouts und führt Rollbacks durch, wenn Health-Checks fehlschlagen.

Das direkte Erstellen von Pods ist in der Produktion fast nie angemessen. Deployments bieten Replikat-Management, Rolling Updates, Rollback-Historie und Pause-/Resume-Funktionalität.

# 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

Die strategy.rollingUpdate-Section definiert das Verhalten für Deployments ohne Downtime. Mit maxUnavailable: 1 und maxSurge: 1 erstellt Kubernetes einen neuen Pod, wartet auf den Readiness-Check, und terminiert dann einen alten Pod. Dieser Zyklus wiederholt sich, bis alle Replikate die neue Version ausführen.

Rollback eines fehlgeschlagenen Kubernetes Deployments

Rollbacks sind ein häufiges Thema in Interviews. Der Deployment-Controller bewahrt alte ReplicaSets auf (gesteuert durch revisionHistoryLimit), sodass ein Rollback sofort erfolgt — kein Image-Rebuild nötig.

# 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

Der undo-Befehl patcht die Deployment-Spec, um sie an das Pod-Template der Ziel-Revision anzupassen. Die Rolling-Update-Strategie greift dann wie gewohnt und ersetzt aktuelle Pods schrittweise durch die Rollback-Version.

Kubernetes Services: Stabiles Networking für dynamische Pods

Pods sind kurzlebig. Sie erhalten bei jedem Neustart neue IP-Adressen. Ein Service löst dieses Problem, indem er eine stabile virtuelle IP (ClusterIP) und einen DNS-Namen bereitstellt, der den Traffic an gesunde Pods weiterleitet, die einem Label-Selector entsprechen.

Die kube-proxy-Komponente auf jedem Node programmiert iptables- oder IPVS-Regeln zur Verteilung des Traffics auf Backend-Pods. Wenn ein Pod seinen Readiness-Probe nicht besteht, entfernt der Endpoints-Controller ihn aus dem Service — kein Traffic erreicht ungesunde Instanzen.

# 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

Nach der Erstellung kann jeder Pod im Cluster diesen Service unter api-service.default.svc.cluster.local (oder einfach api-service innerhalb desselben Namespaces) erreichen. CoreDNS übernimmt die Auflösung.

Service-Typen: ClusterIP, NodePort und LoadBalancer

Interviewer erwarten, dass Kandidaten die drei wichtigsten Service-Typen erklären können und wann welcher zum Einsatz kommt.

| Typ | Zugangsbereich | Anwendungsfall | |-----|----------------|----------------| | ClusterIP | Nur cluster-intern | Backend-APIs, Datenbanken, Caches | | NodePort | Extern über <NodeIP>:<Port> | Entwicklung, Bare-Metal-Cluster | | LoadBalancer | Extern über Cloud-LB | Produktions-Traffic auf AWS/GCP/Azure |

# 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

Der Typ LoadBalancer veranlasst den Load-Balancer-Controller des Cloud-Providers, einen externen Endpunkt bereitzustellen. Auf AWS erstellt dies je nach Annotations einen NLB oder ALB. Auf Bare-Metal-Clustern ohne Cloud-Integration übernehmen MetalLB oder kube-vip diese Rolle.

Deployments und Services über Label Selectors verbinden

Die Verbindung zwischen einem Deployment und einem Service erfolgt ausschließlich über den Label-Selector. Es gibt keinen expliziten Verweis zwischen den beiden Objekten. Der Service überwacht Pods, deren Labels mit seinem spec.selector übereinstimmen, und pflegt automatisch eine Endpoints-Liste.

Diese entkoppelte Architektur bedeutet, dass ein einzelner Service Traffic an Pods aus mehreren Deployments routen kann (nützlich für Canary Releases), und ein Deployment von mehreren Services exponiert werden kann (verschiedene Ports, verschiedene Zugangsebenen).

# 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

Mit dem Haupt-Deployment auf 3 Replikaten und dem Canary auf 1 verteilt der Service ungefähr 25% des Traffics an den Canary. Keine Änderung der Service-Konfiguration nötig — das Label-Matching erledigt alles.

Horizontal Pod Autoscaling für Kubernetes Deployments

Statische Replikat-Zahlen verschwenden Ressourcen bei geringem Traffic und brechen unter Spitzen zusammen. Der HorizontalPodAutoscaler (HPA) passt die Replikat-Anzahl basierend auf beobachteten Metriken an.

# 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

Der HPA fragt den Metrics-Server standardmäßig alle 15 Sekunden ab. Kubernetes v1.35 führte konfigurierbare HPA-Toleranzen ein und ersetzte den fest codierten 10%-Schwellenwert. Teams mit latenzempfindlichen Workloads können nun präzisere Skalierungstrigger setzen.

Der Parameter behavior.scaleDown.stabilizationWindowSeconds verhindert Flapping — schnelle Scale-Up/Scale-Down-Zyklen, verursacht durch stoßweisen Traffic.

Häufige Kubernetes-Interviewfragen mit Antworten

Diese Fragen tauchen regelmäßig in DevOps- und Platform-Engineering-Interviews auf. Jede Antwort zielt auf die Tiefe ab, die Interviewer erwarten.

Was passiert, wenn ein Pod sein Speicherlimit überschreitet? Das kubelet sendet über den OOM-Killer ein SIGKILL. Der Container beendet sich mit Code 137. Der Deployment-Controller erkennt den fehlgeschlagenen Pod und erstellt einen Ersatz, abhängig von der Restart-Policy und eventuellen Backoff-Verzögerungen.

Wie leitet Kubernetes während Canary Releases Traffic an eine bestimmte Pod-Version? Der Service-Selector matcht auf gemeinsame Labels (z.B. app: api). Sowohl das stabile als auch das Canary-Deployment verwenden dieses Label. Die Traffic-Verteilung ist proportional zur Anzahl der bereiten Endpoints — 3 stabile Replikate + 1 Canary-Replikat bedeutet ca. 25% Canary-Traffic. Für präzises Traffic-Splitting (z.B. 5%) wird Gateway API HTTPRoute mit gewichteten Backends verwendet.

Was ist der Unterschied zwischen readinessProbe und livenessProbe? Ein Readiness-Probe steuert, ob der Pod Traffic vom Service erhält. Ein fehlender Readiness-Probe entfernt den Pod aus der Endpoints-Liste, startet ihn aber nicht neu. Ein Liveness-Probe steuert, ob der Container neu gestartet wird. Ein fehlender Liveness-Probe löst einen Container-Neustart aus. Beide können HTTP-, TCP- oder exec-Checks verwenden.

Wie garantieren Rolling Updates Zero Downtime? Der Deployment-Controller erstellt neue Pods, bevor alte terminiert werden, gesteuert durch maxSurge und maxUnavailable. Neue Pods müssen Readiness-Probes bestehen, bevor alte Pods drainiert werden. Die terminationGracePeriodSeconds (Standard: 30s) geben laufenden Anfragen Zeit, sich abzuschließen, bevor SIGKILL gesendet wird.

Die Vorbereitung auf ein Kubernetes-Interview erfordert praktische Erfahrung mit YAML, nicht nur Theorie. Die DevOps-Interviewfragen auf SharpSkill behandeln diese Themen mit interaktiven Übungen.

Zusammenfassung

• Pods sind die Scheduling-Einheit — immer Resource-requests und -limits setzen sowie sowohl Readiness- als auch Liveness-Probes konfigurieren
• Deployments verwalten Replikat-Anzahl, Rolling Updates und Rollback-Historie über ReplicaSets — niemals nackte Pods in der Produktion erstellen
• Services bieten stabiles Networking durch Label-Selectors und virtuelle IPs — ClusterIP für internen Traffic, LoadBalancer für externen
• Die Verbindung zwischen Deployments und Services ist rein label-basiert, was Canary-Patterns ohne Konfigurationsänderungen ermöglicht
• HPA skaliert Deployments basierend auf CPU-/Memory-Metriken — stabilizationWindowSeconds verwenden, um Flapping zu verhindern
• Gateway API ersetzt Ingress NGINX seit Kubernetes v1.35 — neue Projekte sollten sie von Anfang an einsetzen
• Mit echten YAML-Manifesten und kubectl-Befehlen üben, statt Definitionen auswendig zu lernen