Der beste Kubernetes-Test für die Einstellung von SRE- und DevOps-Engineers

Warum Standard-Kubernetes-Tests scheitern

Die meisten Kubernetes-Bewertungen fragen: „Was ist ein StatefulSet?" oder „Erkläre Taints und Tolerations." Das misst Auswendiglernen — nicht, ob jemand einen Cluster entwirft, der einen Node-Ausfall übersteht, erkennt, wann eine App oszilliert, oder debuggt, warum ein Deployment nie stabilisiert.

Eine SRE oder DevOps-Engineerin mit tiefer Kubernetes-Erfahrung weiß, dass die echten Fragen Stabilität, Kosten und das Debuggen von Produktionsproblemen unter Druck betreffen.

So sieht eine signaltragende Kubernetes-Bewertung aus.

Kernkompetenzen zum Prüfen

1. Cluster-Design und Resilienz

Kann sie einen Cluster entwerfen, der Zonenausfälle übersteht?

Frage:

„Du betreibst einen produktiven Workload, der bei Zonenausfällen verfügbar bleiben muss. Du hast einen 3-Knoten-Cluster in einer einzigen AZ. Was änderst du? Was sind die Trade-offs?"

Gute Antwort:

• Knoten über mindestens 3 AZs verteilen
• PodDisruptionBudgets nutzen, um kaskadierende Ausfälle zu verhindern
• Node-Affinity, um Replikate nicht in eine Zone zu konzentrieren
• Health-Checks für Knoten konfigurieren
• Versteht das Kosten-Trade-off (3× Infrastruktur)

Schwache Antwort:

• „Mehr Replikate" (löst das Zonenproblem nicht)
• „Anti-Affinity" (ohne Pod Topology Spread Constraints zu verstehen)

2. Workload-Konfiguration und Debugging

Kann sie für die Produktion konfigurieren und debuggen, wenn etwas schiefgeht?

Frage:

„Du hast einen neuen Microservice deployed. Das Deployment zeigt 3 Replikate, aber nur 2 nehmen Traffic. Readiness-Checks bestehen. Warum?"

Gute Antwort denkt (der Reihe nach):

• Fehlt der Endpoint im Service-Selektor? (kubectl get endpoints)
• Blockiert eine Network Policy den Traffic?
• Ist das Pod-Network-Interface fehlkonfiguriert?
• Unterscheidet sich der Health-Check des Load Balancers vom Readiness-Check?

Das prüft systematisches Debugging, nicht Kubernetes-Faktenwissen.

3. Storage und Zustandsmanagement

Versteht sie, wann StatefulSet vs. Deployment? Wann Node-lokal vs. persistenter Storage?

Frage:

„Wir betreiben Elasticsearch auf Kubernetes. StatefulSet oder Deployment? Was zum Storage?"

Gute Antwort:

• StatefulSet für stabile Identität und Ordnung
• Persistent Volumes für Datenhaltbarkeit
• Anti-Affinity, um über Knoten zu verteilen
• Sorgfältige Upgrade-Strategie (Rolling Restarts können Quorum-Verlust verursachen)

Schwache Antwort:

• „Deployment, ist einfacher"
• Keine Erwähnung von Persistenz oder Quorum

4. Skalierung und Kostenoptimierung

Weiß sie, wann skalieren vs. wann Workloads optimieren?

Frage:

„Cluster-CPU bei 85 %. Kosten 10 k $/Monat. Zwei Optionen: mehr Knoten oder Pod-Requests optimieren. Was prüfst du zuerst?"

Gute Antwort:

• Pods, die zu viele Ressourcen anfordern (Requests zu hoch)
• Noisy-Neighbor-Probleme (ein Pod nutzt unverhältnismäßig viel)
• Ist Workload natürlicherweise spitzenlastig (Traffic verschieben statt skalieren)
• Erst dann Knoten hinzufügen, wenn es echte Engpässe sind

Das misst operatives Urteilsvermögen.

5. Observability und Produktion-Debugging

Kann sie Monitoring entwerfen? Eine flackrige App diagnostizieren?

Frage:

„Deine App in Kubernetes hat 0,1 %-Fehlerspitzen über 30 Sekunden, dann Erholung. Einmal pro Tag zu zufälligen Zeiten. Wie untersuchst du?"

Gute Antwort erwähnt:

• Pod-Restart-Events (Node- und kubelet-Logs)
• Ressourcenerschöpfung (Memory und CPU)
• Netzwerk-Timeouts (Service-Endpoints und DNS)
• App-Level-Retries (erholt sich die App von transienten Fehlern?)

Bewertungsstruktur

Teil 1: Take-home-Designaufgabe (2 Stunden)

Szenario:

„Entwirf einen produktiven Kubernetes-Cluster für eine SaaS-Anwendung mit:

• 99,9 % Uptime-SLA
• Stateless Frontend, stateful Backend (Datenbank)
• 50–500 gleichzeitige Userinnen (variable Last)
• Budget: max. 5.000 $/Monat
• Muss Single-Zone-Ausfall überstehen
• Skalierung muss automatisch sein"

Sie soll liefern:

• Knoten-Architektur (wie viele, Instance-Typen, Zonen)
• Workload-Konfiguration (Deployments, Resource Requests, Skalierungspolicies)
• Storage-Strategie (Persistent Volumes, Backups)
• Monitoring- und Alert-Plan
• Kostenaufstellung

Das prüft, ob sie schon im Maßstab gebaut hat.

Teil 2: Konfigurations-Review (30 Minuten)

Gib ihr ein Kubernetes-Manifest mit absichtlichen Problemen:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  replicas: 1  # Issue: should be 3 for HA
  selector:
    matchLabels:
      app: api-server
  template:
    metadata:
      labels:
        app: api-server
    spec:
      containers:
      - name: api
        image: api:latest  # Issue: should use semantic versioning
        resources:
          requests:
            cpu: 100m  # Issue: too low; app will be CPU throttled
            memory: 64Mi  # Issue: too low; will OOM
      # Issue: no readiness probe, no liveness probe
      # Issue: no node affinity; could run on same node
---
apiVersion: v1
kind: Service
metadata:
  name: api-server
spec:
  selector:
    app: api-server
  ports:
  - port: 80
    targetPort: 8080

Bitte sie, alle Probleme zu identifizieren und die Fixes zu erklären. Eine starke Bewerberin findet 8+, eine schwache 1–2 offensichtliche.

Teil 3: Troubleshooting-Gespräch (30 Minuten)

Szenario:

„Du hast einen neuen Service in Kubernetes deployed. Traffic kommt an, aber Latenz ist 10× normal. Prometheus zeigt normale CPU/Memory. Erkläre, wie du debuggen würdest."

Die Bewerberin sollte fragen:

• Ist der Service-Endpoint aktuell? (kubectl get endpoints)
• Bekommen Pods gleichmäßig Traffic, oder ist einer langsam?
• Liegt es am Netzwerkpfad (kube-proxy, CNI)?
• Blockiert die App auf etwas (externe API, Datenbank)?
• Enthielt der Deploy eine nicht optimierte Codeänderung?

Das prüft systematisches Denken.

Kubernetes-Bewertungsrubrik

Was NICHT testen

Bitte Bewerberinnen nicht darum:

• Einen Kubernetes-Operator von Grund auf zu schreiben. (Das ist Systems-Programming, nicht SRE.)
• API-Versionen auswendig zu kennen. (Sie nutzt in der Produktion sowieso die Docs.)
• Im Interview einen Cluster von Grund auf einzurichten. (Das ist eine Ops-Aufgabe, kein Urteilsvermögens-Check.)

Bitte sie:

• Einen Cluster für realistische Constraints zu entwerfen
• Zu debuggen, warum ein Deployment scheitert
• Trade-offs zwischen Optionen zu erklären
• Workloads für die Produktion zu konfigurieren

Für Teams ohne Kubernetes

Wenn du DevOps oder SRE einstellst, aber Kubernetes noch nicht nutzt, teste Containerisierungs- und Orchestrierungskonzepte, ohne Kubernetes-Expertise zu verlangen. Viele Teams überbewerten Kubernetes-Wissen, wo eigentlich Systemdenken gebraucht wird.

Für Teams, die Kubernetes in Produktion nutzen, evaluiere mit dieser Struktur die operative Tiefe vor dem Hire. Wer diese Bewertung besteht, ist ab Tag 1 produktiv.

Weiter: verstehe, wie du die Ergebnisse deiner DevOps-Bewertung interpretierst.