Kubernetes Deutschland: Interview Fragen für DevOps Jobs

TL;DR

• Dieser Guide bereitet Sie optimal auf gängige Kubernetes Interview Fragen für DevOps-Rollen im deutschen Kubernetes-Umfeld vor.
• Er enthält 50 essenzielle Fragen aus allen relevanten Bereichen wie Architektur, Netzwerk, Storage und Sicherheit.
• Sie erhalten prägnante, praxiserprobte Musterantworten, die über reines Theoriewissen hinausgehen.
• Der Fokus liegt auf technischer Tiefe, praktischer Erfahrung und Problemlösungskompetenz, essenziell für den Erfolg im deutschsprachigen Raum.
• Ideal für DevOps- und Platform Engineers, die sich auf das nächste Bewerbungsgespräch vorbereiten und ihre Expertise im deutschen Kubernetes-Markt zeigen möchten.

Ein solides Verständnis von Kubernetes ist heute für jeden DevOps oder Platform Engineer in Deutschland unverzichtbar. Im Bewerbungsgespräch geht es nicht nur darum, Definitionen herunterzubeten, sondern auch, Ihr praktisches Wissen und Ihre Problemlösungskompetenz unter Beweis zu stellen. Gerade im Kontext der zunehmenden Adaption von Kubernetes in Unternehmen, sind fundierte Kenntnisse gefragt. Dieser Artikel liefert Ihnen 50 häufig gestellte Kubernetes Interview Fragen für DevOps-Positionen und hilft Ihnen, Ihre Antworten zu schärfen, um Ihre Expertise zu unterstreichen.

50 Kubernetes Interview Fragen für DevOps Jobs

Wir haben die Fragen in verschiedene Kategorien unterteilt, um eine strukturierte Vorbereitung zu ermöglichen. Beachten Sie, dass die Schwierigkeit innerhalb der Kategorien variieren kann, von grundlegendem Verständnis bis hin zu detaillierten Debugging-Szenarien, die in komplexen Projekten häufig auftreten.

I. Grundlagen und Architektur

Für viele Unternehmen ist Kubernetes die Basis moderner Cloud-Native-Strategien. Ein tiefes Verständnis der Architektur ist daher essenziell.

1. Was ist Kubernetes und warum ist es so wichtig für DevOps-Rollen? Kubernetes ist eine Open-Source-Plattform zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen. Es ist wichtig, weil es die Komplexität des Betriebs verteilter Systeme reduziert, Hochverfügbarkeit ermöglicht und die Ressourcennutzung optimiert. Für DevOps-Rollen ist es entscheidend, da es die Grundlage für effiziente CI/CD-Pipelines und den Betrieb moderner Software-Produkte bildet.

2. Erklären Sie die Kernkomponenten eines Kubernetes-Clusters. Ein Cluster besteht aus der Control Plane (Master-Komponenten wie API Server, etcd, Scheduler, Controller Manager) und Worker Nodes (mit Kubelet, Kube-Proxy und einer Container Runtime wie containerd). Dieses Modell ist universell und auch für Implementierungen auf dem deutschen Markt relevant.

3. Was ist der Unterschied zwischen einem Pod und einem Container? Ein Container ist eine isolierte Ausführungseinheit für eine Anwendung. Ein Pod ist die kleinste deploybare Einheit in Kubernetes und kann einen oder mehrere Container enthalten, die sich Ressourcen und Netzwerknamenraum teilen.

4. Was ist ein Deployment und wofür wird es verwendet? Ein Deployment ist ein Kubernetes-Objekt, das die deklarative Aktualisierung von Pods und ReplicaSets ermöglicht. Es beschreibt den gewünschten Zustand einer Anwendung, z.B. wie viele Replicas laufen sollen und welches Container-Image verwendet wird.

5. Wie funktioniert ein Rollout bei einem Deployment? Bei einem Rollout erstellt Kubernetes ein neues ReplicaSet für die neue Version und skaliert es schrittweise hoch, während das alte ReplicaSet heruntergefahren wird (Rolling Update-Strategie). Dies gewährleistet eine Zero-Downtime-Bereitstellung, ein wichtiges Ziel in jedem Kubernetes-Projekt.

6. Was ist ein ReplicaSet? Ein ReplicaSet stellt sicher, dass eine bestimmte Anzahl von Pod-Replicas zu jeder Zeit läuft. Es ist der zugrundeliegende Controller, den Deployments nutzen.

7. Erklären Sie kube-apiserver, kube-scheduler und kube-controller-manager.

   • kube-apiserver: Front-End der Kubernetes Control Plane, stellt die API zur Interaktion bereit.
   • kube-scheduler: Wählt für neue Pods einen passenden Node aus, basierend auf Ressourcenanforderungen und Constraints.
   • kube-controller-manager: Führt Controller aus, die den aktuellen Zustand des Clusters mit dem gewünschten Zustand abgleichen (z.B. ReplicaSet Controller).

8. Wofür dient etcd in Kubernetes? etcd ist ein hochverfügbarer Key-Value-Store, der alle Cluster-Daten speichert, einschließlich der Konfiguration, des Status und der Metadaten der Objekte.

9. Was ist kubelet? kubelet ist der Agent, der auf jedem Worker Node läuft. Er stellt sicher, dass die Container in den Pods laufen und gesund sind, und kommuniziert mit der Control Plane.

10. Was ist ein Namespace? Ein Namespace bietet einen Mechanismus zur logischen Isolation von Ressourcen innerhalb eines Clusters. Er hilft, Ressourcen für verschiedene Teams oder Umgebungen zu organisieren und Zugriffsrichtlinien anzuwenden, was bei größeren Installationen unerlässlich ist.

II. Networking & Services

Die Vernetzung in Kubernetes ist komplex, aber entscheidend für die Erreichbarkeit und Kommunikation von Anwendungen.

11. Wie erreichen Pods einander innerhalb eines Clusters? Pods kommunizieren über ein flaches Netzwerk, in dem jeder Pod eine einzigartige IP-Adresse erhält. Die Pods können sich direkt erreichen. Ein CNI (Container Network Interface) Plugin implementiert die Netzwerkinfrastruktur.

12. Was ist ein Service und welche Typen gibt es? Ein Service ist eine abstrakte Möglichkeit, eine Gruppe von Pods, die die gleiche Funktion erfüllen, freizulegen. Typen:

    • ClusterIP: Nur innerhalb des Clusters erreichbar.
    • NodePort: Macht den Service auf einem statischen Port auf jedem Node verfügbar.
    • LoadBalancer: Stellt externen Zugriff über einen Cloud-Provider-Load-Balancer bereit.
    • ExternalName: Leitet den Service auf einen externen DNS-Namen um.

13. Erklären Sie den Zweck von kube-proxy. kube-proxy läuft auf jedem Node und ist für die Implementierung der Service-Abstraktion verantwortlich. Es verwaltet Netzwerkregeln (oft iptables oder IPVS) für die Weiterleitung von Traffic zu den korrekten Pods eines Services.

14. Was ist ein Ingress? Ein Ingress ist ein API-Objekt, das externen Zugriff auf Services innerhalb des Clusters ermöglicht, typischerweise HTTP/HTTPS-Routing. Es erfordert einen Ingress Controller (z.B. NGINX, HAProxy), der die Ingress-Regeln implementiert.

15. Wann würden Sie einen NodePort im Vergleich zu einem LoadBalancer Service verwenden? NodePort ist nützlich für Testzwecke oder wenn Sie einen eigenen externen Load Balancer vor den Nodes haben. LoadBalancer ist die Standardmethode, um in einer Cloud-Umgebung einen externen, stabilen Zugriffspunkt für einen Service zu erhalten, da er automatisch einen Cloud-Load-Balancer provisioniert.

16. Wie funktioniert DNS-Auflösung innerhalb von Kubernetes? Kubernetes verwendet CoreDNS (oder früher Kube-DNS) als Cluster-DNS. Services und Pods erhalten DNS-Namen, die automatisch registriert werden. Pods können andere Services über deren DNS-Namen erreichen (z.B. my-service.my-namespace.svc.cluster.local).

17. Was ist ein Headless Service? Wann ist er sinnvoll? Ein Headless Service hat keinen ClusterIP und keinen Load Balancer. Stattdessen gibt er direkt die IP-Adressen der Backend-Pods per DNS zurück. Er ist sinnvoll für StatefulSets oder wenn Sie die Pod-IPs direkt benötigen, z.B. für Datenbank-Cluster-Kommunikation.

18. Was ist ein NetworkPolicy? Ein NetworkPolicy ist ein API-Objekt, das Regeln für den Netzwerkverkehr zwischen Pods und/oder externen Endpunkten definiert. Es ermöglicht die Isolation von Pods und die Implementierung von Zero-Trust-Prinzipien, ein wichtiger Sicherheitsaspekt bei Kubernetes-Implementierungen.

19. Wie routet ein Ingress-Controller den Traffic an die richtigen Services? Der Ingress-Controller überwacht Ingress-Ressourcen und konfiguriert basierend darauf seine eigenen Routing-Regeln. Er leitet Anfragen basierend auf Hostnamen und/oder Pfaden zu den entsprechenden ClusterIP-Services weiter.

20. Was ist die Bedeutung von TargetPort und Port in einem Service-Definition?

    • port: Der Port, auf dem der Service Anfragen im Cluster empfängt.
    • targetPort: Der Port, auf dem der Container im Pod lauscht und den der Service ansteuert.

III. Storage & Persistenz

Der Umgang mit persistenten Daten ist eine der größten Herausforderungen bei der Arbeit mit Kubernetes. Insbesondere für Anwendungen im deutschen Raum sind sichere und zuverlässige Storage-Lösungen gefragt.

21. Was ist der Unterschied zwischen PersistentVolume (PV) und PersistentVolumeClaim (PVC)?

    • PV: Eine abstrahierte Storage-Ressource im Cluster, die von einem Administrator provisioniert oder dynamisch erstellt wird (z.B. ein NFS-Mount, EBS-Volume).
    • PVC: Eine Anforderung eines Pods an den Cluster, eine bestimmte Menge und Art von Storage zu erhalten. Der PVC bindet sich an ein passendes PV.

22. Erklären Sie, wie dynamische Volume-Provisionierung funktioniert. Wenn ein PVC erstellt wird, der kein passendes, manuell provisioniertes PV findet, kann ein StorageClass dynamisch ein neues PV erstellen, das den Anforderungen des PVC entspricht (z.B. ein neues EBS-Volume in AWS). Dies ist Standard in vielen Kubernetes-Setups.

23. Was ist ein StorageClass? Ein StorageClass definiert die "Klassen" von Storage, die in einem Cluster verfügbar sind. Es legt fest, welcher Provisioner verwendet wird und welche Parameter (z.B. Performance-Tier, Replikation) für dynamisch provisionierten Storage gelten.

24. Wann würden Sie ein EmptyDir Volume verwenden? Ein EmptyDir Volume wird verwendet, wenn temporärer Speicher benötigt wird, der mit dem Lebenszyklus des Pods verbunden ist. Die Daten gehen verloren, wenn der Pod beendet wird. Nützlich für Caching oder Zwischenspeicherung.

25. Was ist ein HostPath Volume? Wann sollte man vorsichtig sein? Ein HostPath Volume mountet ein Verzeichnis vom Host-Node in einen Pod. Man sollte vorsichtig sein, da es Sicherheitsrisiken birgt (Pod kann auf Host-Dateisystem zugreifen) und die Pod-Portabilität einschränkt (Pod ist an spezifischen Host gebunden). Dies sollte in einer Produktionsumgebung vermieden werden.

26. Wie stellen Sie sicher, dass Ihre Stateful Applications Daten nicht verlieren? Durch die Verwendung von PersistentVolumes und PersistentVolumeClaims, idealerweise in Kombination mit StatefulSets. Zusätzlich sind regelmäßige Backups der Daten essenziell, um die Datenkonsistenz zu gewährleisten.

27. Was ist ein StatefulSet? Ein StatefulSet ist ein Controller, der für die Bereitstellung von Anwendungen mit persistentem Storage und stabilen, eindeutigen Identitäten (Netzwerk-IDs, Storage-Namen) für deren Pods entwickelt wurde. Ideal für Datenbanken oder Messaging-Queues.

28. Was ist der Unterschied zwischen einem ReadWriteOnce und ReadWriteMany Access Mode?

    • ReadWriteOnce (RWO): Das Volume kann von einem einzelnen Node gemountet und beschrieben werden.
    • ReadWriteMany (RWX): Das Volume kann von mehreren Nodes gleichzeitig gemountet und beschrieben werden. (Oft für Shared Storage wie NFS)

29. Wie würden Sie eine Datenbank in Kubernetes betreiben – Deployment oder StatefulSet? Für Datenbanken ist ein StatefulSet vorzuziehen. Es bietet stabile Netzwerk-Identitäten, geordnete Start- und Shutdown-Prozeduren und die Möglichkeit, jedem Pod ein eigenes, persistentes Volume zuzuweisen, was für Datenkonsistenz entscheidend ist.

30. Wie sichern Sie Daten auf Persistent Volumes? Dies geschieht in der Regel durch externe Backup-Lösungen, die Snapshot-Funktionalitäten der zugrunde liegenden Storage-Systeme nutzen (z.B. Velero für Kubernetes-Ressourcen und PV-Snapshots) oder durch anwendungsspezifische Datenbank-Backups. Dies ist ein kritischer Punkt für jede Infrastruktur, besonders im Hinblick auf Compliance und DSGVO.

IV. Sicherheit & Best Practices

Sicherheit ist kein nachträglicher Gedanke, sondern muss integraler Bestandteil jeder Kubernetes-Strategie sein. Insbesondere im deutschen Markt sind strikte Datenschutz- und Sicherheitsanforderungen zu beachten.

31. Was sind Security Contexts und wofür werden sie verwendet? SecurityContexts definieren Privileg- und Zugriffskontrolleinstellungen für einen Pod oder Container. Sie können Dinge wie runAsUser, runAsGroup, allowPrivilegeEscalation oder capabilities festlegen, um die Sicherheit zu erhöhen.

32. Was ist ein ServiceAccount und wofür wird er benötigt? Ein ServiceAccount stellt eine Identität für Prozesse bereit, die in Pods laufen, um auf die Kubernetes API zuzugreifen. Pods werden standardmäßig mit einem default ServiceAccount provisioniert, aber es ist Best Practice, dedizierte ServiceAccounts mit minimalen Rechten zu verwenden.

33. Erklären Sie Role-Based Access Control (RBAC) in Kubernetes. RBAC ermöglicht die detaillierte Steuerung, welche Benutzer oder ServiceAccounts welche Aktionen auf welche Ressourcen innerhalb eines Clusters ausführen dürfen. Es besteht aus Roles (Berechtigungssätze in einem Namespace) oder ClusterRoles (Cluster-weite Berechtigungen) und RoleBindings oder ClusterRoleBindings, die diese Rollen an Benutzer/ServiceAccounts binden. Ein Muss für sichere Kubernetes-Umgebungen, auch um BSI-Grundschutz-Anforderungen zu erfüllen.

34. Warum sollte man Root-Container in Pods vermeiden? Das Ausführen von Containern als Root erhöht das Angriffsrisiko erheblich. Bei einer Kompromittierung des Containers hat der Angreifer potenziell Root-Rechte im Container und könnte versuchen, aus dem Container auszubrechen.

35. Was ist ein NetworkPolicy und wie trägt es zur Sicherheit bei? Ein NetworkPolicy definiert Regeln für den Netzwerkverkehr zwischen Pods. Es trägt zur Sicherheit bei, indem es Mikro-Segmentierung ermöglicht, d.h. die Kommunikation zwischen Pods auf das absolute Minimum beschränkt und somit die laterale Bewegung eines Angreifers einschränkt.

36. Wie verwalten Sie Secrets in Kubernetes? Secrets sind Kubernetes-Objekte zum Speichern sensibler Daten wie Passwörter, OAuth-Token oder SSH-Schlüssel. Sie werden Base64-kodiert gespeichert (nicht verschlüsselt!) und können als Environment-Variablen oder gemountete Dateien in Pods injiziert werden. Für echten Schutz empfiehlt sich die Integration mit externen Secret Managern (z.B. Vault, AWS Secrets Manager) oder Tools wie Sealed Secrets, um hohe Anforderungen an Datensicherheit und Compliance zu erfüllen.

37. Was sind Admission Controllers? Nennen Sie ein Beispiel. Admission Controllers sind Code-Blöcke, die Anfragen an den Kubernetes API Server abfangen, bevor ein Objekt persistent in etcd gespeichert wird. Sie können die Anfrage validieren, mutieren oder ablehnen. Beispiel: LimitRanger (erzwingt Resource Quotas).

38. Was sind Pod Security Standards (PSS)? Die Pod Security Standards definieren drei Stufen von Sicherheitsanforderungen (Privileged, Baseline, Restricted) für Pods, um die Sicherheit von Workloads zu gewährleisten. Sie sind die Nachfolger der Pod Security Policies (PSPs) und werden über Pod Security Admission erzwungen. Die Einhaltung dieser Standards ist grundlegend für eine robuste Sicherheitsstrategie.

39. Wie stellen Sie sicher, dass nur vertrauenswürdige Container-Images in Ihrem Cluster laufen? Durch die Implementierung einer Image-Policy mit Admission Controllern (z.B. Kyverno, OPA Gatekeeper), die nur Images aus genehmigten Registries oder mit bestimmten Signaturen zulassen. Regelmäßiges Image Scanning ist ebenfalls entscheidend für die Sicherheit von Kubernetes-Deployments.

40. Nennen Sie zwei Best Practices für die Sicherheit in Kubernetes.

    1. Least Privilege: Minimale Berechtigungen für ServiceAccounts, Pods und Benutzer.
    2. Network Policies: Implementierung von Netzwerk-Mikro-Segmentierung zur Begrenzung von Lateral Movement.
    3. Image Scanning: Regelmäßiges Scannen von Container-Images auf Schwachstellen.
    4. Pod Security Standards: Erzwingen von PSS, um Pods sicherer zu betreiben und Compliance zu gewährleisten.

V. Troubleshooting & Debugging

Effizientes Troubleshooting ist das A und O im DevOps-Alltag mit Kubernetes. Diese Fragen testen Ihre praktischen Fähigkeiten zur Problemlösung.

41. Ein Pod ist im Status Pending. Was sind mögliche Ursachen?

    • Nicht genügend Ressourcen auf den Nodes (CPU, Memory).
    • Falsche oder nicht verfügbare PersistentVolumeClaims.
    • Fehlende Node-Selektoren, Taints oder Tolerations, die verhindern, dass der Pod auf einem Node platziert wird.
    • Unzureichender oder nicht verfügbarer StorageClass-Provisioner.
    • Image Pull Fehler.

42. Ein Pod ist im Status CrashLoopBackOff. Wie debuggen Sie das?

    1. kubectl describe pod <pod-name>: Prüfen Sie die Events für Fehlermeldungen.
    2. kubectl logs <pod-name>: Lesen Sie die Container-Logs.
    3. kubectl logs -p <pod-name>: Zeigt Logs des vorherigen, abgestürzten Containers.
    4. kubectl exec -it <pod-name> -- /bin/bash: Versuchen Sie, in den Container zu gelangen, um das Problem zu untersuchen (falls er kurz läuft).

43. Sie können Ihren Service von außerhalb des Clusters nicht erreichen. Was könnten die Probleme sein?

    • Falscher Service-Typ (z.B. ClusterIP statt NodePort/LoadBalancer).
    • Firewall-Regeln auf dem Cloud-Provider oder im Cluster selbst (NetworkPolicy, Security Groups).
    • Inkorrekte Selector-Labels im Service, die keine Pods finden.
    • Ingress-Controller nicht installiert oder falsch konfiguriert.
    • Service ist nicht bereit (z.B. Pods im CrashLoop).

44. Ihr Deployment bleibt nach einem Update hängen. Wie würden Sie das beheben?

    1. kubectl get events und kubectl describe deployment <deployment-name>: Prüfen Sie auf Rollout-Fehler, Image-Probleme oder Resource Quotas.
    2. kubectl rollout status deployment/<deployment-name>: Zeigt den Status des Rollouts.
    3. kubectl rollout undo deployment/<deployment-name>: Führt ein Rollback zur vorherigen stabilen Version durch.

45. Was ist der Unterschied zwischen Liveness- und Readiness-Probes?

    • Liveness-Probe: Prüft, ob ein Container noch läuft und als "lebendig" gilt. Schlägt sie fehl, wird der Container neu gestartet.
    • Readiness-Probe: Prüft, ob ein Container bereit ist, Traffic zu empfangen. Schlägt sie fehl, wird der Pod aus dem Service-Endpunkt entfernt, bis er wieder bereit ist.

46. Welche kubectl Befehle nutzen Sie am häufigsten zum Debuggen? get, describe, logs, exec, port-forward, top, events.

47. Ein Pod kann nicht auf ein PersistentVolume zugreifen. Was überprüfen Sie zuerst?

    1. Ist der PVC an ein PV gebunden? (kubectl get pvc <pvc-name>)
    2. Stimmt der Access Mode (ReadWriteOnce, ReadWriteMany) mit den Anforderungen überein?
    3. Gibt es Fehler im Storage-System selbst oder im CSI-Treiber? (kubectl logs -n <csi-namespace> <csi-controller-pod>)
    4. Ist das Volume auf dem Node gemountet und der Pod-Pfad korrekt?

48. Wie können Sie die CPU- und Speichernutzung Ihrer Pods überprüfen? Mit kubectl top pod <pod-name> oder kubectl top node <node-name>. Dafür muss der Metrics Server im Cluster installiert sein.

49. Was tun Sie, wenn ein Node den Status NotReady hat?

    1. SSH auf den Node: Ist der kubelet Dienst aktiv und läuft? (systemctl status kubelet)
    2. Gibt es ausreichend Ressourcen auf dem Node (Disk Space, Memory, CPU)?
    3. Überprüfen Sie die Node-Logs (journalctl -u kubelet).
    4. Gibt es Netzwerkprobleme zwischen dem Node und der Control Plane?

50. Wie überprüfen Sie die Logs der Control Plane Komponenten (API Server, Scheduler, Controller Manager)? Da diese oft als statische Pods oder Systemd-Dienste auf den Master-Nodes laufen, kann man die Logs über kubectl logs -n kube-system <pod-name> (wenn es Pods sind) oder direkt auf dem Master-Node via journalctl -u <component-name> (z.B. journalctl -u kube-apiserver) einsehen.

Fazit

Die Beherrschung dieser Kubernetes Interview Fragen für DevOps- und Platform Engineer-Rollen wird Ihnen nicht nur helfen, das nächste Gespräch in Deutschland erfolgreich zu meistern, sondern auch Ihr Verständnis der zugrundeliegenden Konzepte vertiefen. Zeigen Sie nicht nur Ihr Wissen, sondern auch, wie Sie Probleme praktisch lösen. Die Nachfrage nach Experten für Kubernetes wächst stetig, und fundierte Kenntnisse sind der Schlüssel zum Erfolg und zur Sicherung Ihrer Karrierechancen im deutschen Kubernetes-Umfeld.

Benötigen Sie praktische Unterstützung beim Aufbau oder der Optimierung Ihrer Kubernetes-Plattform oder spezifische Beratung zu Compliance und regulatorischen Anforderungen in Deutschland? Wir helfen Ihnen gerne weiter. Kontaktieren Sie uns jetzt für eine unverbindliche Expertenberatung!

Weiterführende Artikel

• Kubernetes Pod Pending lösen: Ursachen und Fixes
• Kubernetes Storage: CSI Driver und PV einrichten
• Platform Engineering: Self-Service auf Kubernetes
• Kubernetes Schwachstellen finden und patchen
• Container Image Scanning: Trivy vs Grype vs Snyk