Kubernetes-Interviews gehen über Vokabeln (Pod, Deployment, Service) hinaus und drehen sich um den Betrieb (was passiert, wenn ein Pod abstürzt, wie man ein hängendes Rollout debuggt) und das Design (wie man eine Anwendung sicher betreibt). Interviewer mögen Befehle und Symptome, also übe, laut zu sagen, was du tatsächlich eintippen würdest und was du erwarten würdest zu sehen.
Unten findest du 26 Fragen mit Antworten, gruppiert nach Thema. Ersetze die Beispiele wo möglich durch deine eigene Cluster-Erfahrung.
Architektur und Objekte
1. Was ist Kubernetes?
Ein Open-Source-System zum Ausführen und Verwalten von Containern über einen Cluster von Maschinen hinweg. Du deklarierst den gewünschten Zustand, etwa drei Kopien eines Service, und Kubernetes arbeitet kontinuierlich daran, diesen zu erreichen.
2. Was sind die Hauptkomponenten eines Clusters?
Die Control Plane umfasst den API-Server (die Eingangstür), etcd (den Datenspeicher), den Scheduler (der jedem Pod einen Node zuweist) und den Controller Manager (der die Control Loops ausführt). Jeder Worker-Node führt den Kubelet (der Pods ausführt), eine Container-Runtime und kube-proxy (das die Service-Netzwerkkommunikation übernimmt) aus.
3. Was ist ein Pod?
Die kleinste deploybare Einheit. Er enthält einen oder mehrere Container, die sich einen Netzwerk-Namespace und Speicher teilen. Die meisten Pods haben einen Hauptcontainer, und zusätzliche Container sind Sidecars oder Init-Container.
4. Was ist der Unterschied zwischen einem Deployment, einem ReplicaSet und einem StatefulSet?
Ein ReplicaSet hält eine Anzahl identischer Pods am Laufen. Ein Deployment verwaltet ReplicaSets und bietet dir Rolling Updates und Rollbacks. Ein StatefulSet ist für zustandsbehaftete Anwendungen: Pods erhalten stabile Namen, stabilen Speicher und ein geordnetes Starten und Stoppen.
5. Was ist ein DaemonSet? Ein Job? Ein CronJob?
Ein DaemonSet führt einen Pod pro Node aus, für Agents wie Log-Sammler. Ein Job führt eine Aufgabe bis zum Abschluss aus. Ein CronJob führt Jobs nach einem Zeitplan aus.
6. Was sind Labels, Selektoren und Annotations?
Labels sind Key-Value-Paare auf Objekten, und Selektoren wählen Objekte anhand von Labels aus. Services finden Pods auf diese Weise, und Deployments finden ihre ReplicaSets. Annotations enthalten ebenfalls Key-Value-Daten, sind aber für nicht-identifizierende Metadaten gedacht, die von Tools verwendet werden.
7. Was ist ein Namespace?
Eine Möglichkeit, einen Cluster in virtuelle Gruppen zu unterteilen, meist nach Team oder Umgebung. Namespaces begrenzen Namen, und du kannst Ressourcen-Quotas und Zugriffsregeln pro Namespace anwenden. Sie sind für sich genommen keine starke Sicherheitsgrenze.
Netzwerk
8. Was sind die Service-Typen?
| Typ | Was er macht |
|---|---|
| ClusterIP | Eine stabile interne IP, nur innerhalb des Clusters erreichbar (Standard) |
| NodePort | Öffnet einen Port auf jedem Node |
| LoadBalancer | Erstellt einen externen Load Balancer über den Cloud-Anbieter |
| ExternalName | Ordnet den Service einem DNS-Namen zu |
9. Was ist ein Ingress?
Ein Objekt, das externen HTTP- und HTTPS-Traffic anhand von Host und Pfad an Services weiterleitet, wobei ein Ingress-Controller die Arbeit übernimmt. Die neuere Gateway API ist ein ausdrucksstärkerer Nachfolger.
10. Wie finden Pods einander?
Über Services und Cluster-DNS. Ein Service namens api im Namespace shop ist unter api.shop.svc.cluster.local erreichbar, oder einfach unter api aus demselben Namespace heraus.
11. Was ist eine NetworkPolicy?
Ein Regelsatz, der steuert, welche Pods miteinander kommunizieren dürfen. Standardmäßig können alle Pods einander erreichen. Mit Policies (und einem Netzwerk-Plugin, das sie durchsetzt) kannst du den Traffic einschränken, zum Beispiel nur den API-Pods erlauben, die Datenbank zu erreichen.
Konfiguration und Speicher
12. Was ist der Unterschied zwischen einer ConfigMap und einem Secret?
Beide enthalten Konfiguration, die als Umgebungsvariablen oder Dateien eingefügt wird. Secrets sind für sensible Daten gedacht, aber standardmäßig sind sie nur base64-kodiert, nicht verschlüsselt. Aktiviere die Verschlüsselung im Ruhezustand, beschränke den Zugriff mit RBAC und ziehe einen externen Secrets-Manager in Betracht.
13. Was sind PersistentVolumes und PersistentVolumeClaims?
Ein PersistentVolume ist ein Stück Speicher im Cluster. Ein PersistentVolumeClaim ist die Speicheranforderung eines Pods. Eine StorageClass ermöglicht es Kubernetes, Volumes automatisch bereitzustellen. Daten im normalen Container-Dateisystem verschwinden, wenn der Pod ersetzt wird.
14. Was sind Requests und Limits?
Requests sind die Ressourcen, die der Scheduler für einen Container reserviert. Limits sind das Maximum, das er nutzen kann. Wird ein Memory-Limit überschritten, wird der Container beendet (OOMKilled), während das Überschreiten eines CPU-Limits zu Throttling führt.
Zuverlässigkeit und Updates
15. Was sind Liveness-, Readiness- und Startup-Probes?
Liveness prüft, ob der Container neu gestartet werden soll. Readiness prüft, ob er Traffic empfangen darf. Startup gibt langsam startenden Apps Zeit, bevor die anderen Probes beginnen. Ein häufiger Fehler ist eine Liveness-Probe, die von einer Datenbank abhängt – dann startet bei einem Datenbankausfall jeder Pod neu.
16. Wie funktioniert ein Rolling Update?
Das Deployment erstellt neue Pods und entfernt alte schrittweise, gesteuert über maxSurge und maxUnavailable. Readiness-Probes entscheiden, wann ein neuer Pod als bereit gilt. Geht etwas schief, bringt kubectl rollout undo die vorherige Revision zurück.
17. Wie funktioniert Autoscaling?
Der Horizontal Pod Autoscaler ändert die Anzahl der Pods anhand von Metriken wie CPU. Der Vertical Pod Autoscaler passt Requests und Limits an. Der Cluster-Autoscaler fügt Nodes hinzu oder entfernt sie, wenn Pods nicht geplant werden können oder Nodes unterausgelastet sind.
18. Wie hältst du eine App während Node-Wartungsarbeiten verfügbar?
Betreibe mehrere Replicas, verteile sie über Nodes oder Zonen und setze ein PodDisruptionBudget, damit freiwillige Evictions ein Minimum an laufenden Pods erhalten. Leere Nodes mit kubectl drain.
Fehlerbehebung
19. Ein Pod ist im CrashLoopBackOff. Was tust du?
Der Container startet und beendet sich immer wieder. Führe kubectl logs <pod> --previous aus, um den Grund für den Fehler zu sehen, kubectl describe pod für Events, Exit-Codes und fehlgeschlagene Probes, und prüfe die Konfiguration, fehlende Secrets und Ressourcenlimits.
20. Ein Pod hängt in Pending fest. Was prüfst du?
kubectl describe pod zeigt, warum der Scheduler ihn nicht platzieren konnte: nicht genug CPU oder Speicher auf irgendeinem Node, Node-Selektoren oder Taints, die nicht passen, oder ein nicht gebundener Volume-Claim.
21. Ein Pod wurde OOMKilled. Was tust du?
Er hat sein Speicherlimit überschritten. Prüfe den Nutzungstrend, finde heraus, ob es ein Leck gibt oder das Limit einfach zu niedrig ist, und erhöhe das Limit oder behebe die App. Setze Requests nahe am tatsächlichen Verbrauch, damit die Planung realistisch ist.
22. Ein Service ist nicht erreichbar. Wie debuggst du das?
- Prüfe, ob die Pods laufen und bereit sind.
- Prüfe, ob der Selektor des Service zu den Pod-Labels passt (kubectl get endpoints).
- Teste aus dem Cluster heraus mit einem temporären Pod.
- Prüfe den Port, den Target-Port und die Listening-Adresse des Containers.
- Prüfe Network Policies, dann Ingress und DNS.
Sicherheit und Betrieb
23. Wie funktioniert RBAC?
Rollen definieren Berechtigungen für Ressourcen, und Bindings weisen sie Nutzern, Gruppen oder Service Accounts zu. Nutze nach Möglichkeit namensraumbezogene Roles, vermeide cluster-admin und gib jedem Workload einen eigenen Service Account mit den minimal nötigen Berechtigungen.
24. Wie sicherst du einen Cluster ab?
Nutze RBAC mit Least Privilege, beschränke den API-Zugriff, scanne Images, führe Container als Non-Root mit einem schreibgeschützten Dateisystem aus, wo möglich, wende Network Policies an, verschlüssele Secrets, halte Kubernetes aktuell und auditiere Aktivitäten.
25. Was ist Helm?
Ein Paketmanager für Kubernetes. Ein Chart ist eine Sammlung templatisierter Manifeste, und ein Release ist eine installierte Instanz mit eigenen Values. Es hilft dir, Deployments über Umgebungen hinweg wiederzuverwenden und zu versionieren. Kustomize ist ein anderer Ansatz, der einfache Manifeste patcht.
26. Wie würdest du eine Web-App sicher auf Kubernetes deployen?
„Ein Deployment mit mindestens drei Replicas, über Zonen verteilt, Requests und Limits gesetzt, Readiness- und Liveness-Probes, ein Service und ein Ingress mit TLS, Konfiguration in ConfigMaps und Secrets, ein HPA und ein PodDisruptionBudget. Deploye über eine Pipeline mit Rolling Updates und einfachem Rollback und beobachte während des Rollouts Fehlerrate und Latenz."
Wichtige Befehle
| Aufgabe | Befehl |
|---|---|
| Pods auflisten | kubectl get pods -n <namespace> |
| Pod-Details und Events | kubectl describe pod <pod> |
| Logs | kubectl logs <pod> -c <container> (nach einem Absturz --previous anhängen) |
| Shell in einem Pod | kubectl exec -it <pod> -- sh |
| Zurückrollen | kubectl rollout undo deployment/<name> |
| Skalieren | kubectl scale deployment/<name> --replicas=5 |
| Ein Manifest anwenden | kubectl apply -f file.yaml |
So bereitest du dich vor
Betreibe lokal einen kleinen Cluster mit kind oder minikube und mach absichtlich Dinge kaputt: ein falscher Image-Tag, eine fehlschlagende Probe, ein zu niedriges Speicherlimit. Übe, die Ausgabe von describe und logs zu lesen. Bereite einen echten Vorfall vor, den du bearbeitet hast, und was du danach geändert hast. Für Design-Übungen sieh dir unseren System-Design-Leitfaden an, und für Cloud-Themen den AWS-Interview-Leitfaden.
Sag deine Debugging-Schritte laut auf, denn Interviewer achten auf deine Reihenfolge der Prüfungen. Ein Mock-Interview mit Transkript zeigt dir, wo du einen Schritt übersprungen hast. Befolge in jedem Live-Interview die Regeln des Arbeitgebers zu KI-Tools.
Übe Kubernetes Interview-Antworten mit YesToTheOffer
Führe ein Mock-Technical-Interview durch, sprich deine Debugging-Schritte durch und überprüfe anschließend dein Transkript. 30 kostenlose Minuten, kein Abonnement.
