Kubernetes-Team kuendigt: Was 500-MA-Unternehmen jetzt tun muessen

TL;DR

• Wenn Ihr einziger Kubernetes-Admin kuendigt, haben Sie typischerweise 4-8 Wochen, um das gesamte Cluster-Wissen zu sichern -- die meisten Unternehmen schaffen das nicht ohne externe Hilfe.
• Starten Sie am ersten Tag mit einer strukturierten Wissensdokumentation: Cluster-Architektur, Zugangsdaten, Runbooks, Alerting-Regeln und Deployment-Pipelines.
• Recruiting dauert im deutschen Markt 3-6 Monate fuer erfahrene Kubernetes-Engineers -- diese Luecke muss ueberbrueckt werden.
• Ein Managed Service Provider kann innerhalb von 1-2 Wochen den operativen Betrieb uebernehmen und so die kritische Uebergangsphase absichern.
• Langfristig schuetzt nur ein dokumentierter Betrieb mit mehreren Wissenstraegern oder eine externe Betriebspartnerschaft vor dem naechsten Wissensverlust.

Warum die Kuendigung eines Kubernetes-Admins ein Unternehmen lahmlegen kann

In einem typischen Mittelstandsunternehmen mit 300 bis 1000 Mitarbeitern gibt es eine oder maximal zwei Personen, die den Kubernetes-Cluster verstehen. Nicht oberflaechlich, sondern wirklich verstehen: Die Netzwerk-Konfiguration, die Alerting-Regeln, die Backup-Strategie, die Eigenheiten der CI/CD-Pipeline.

Wenn diese Person kuendigt, passiert in den ersten Tagen meistens nichts Sichtbares. Der Cluster laeuft weiter. Die Deployments funktionieren. Dann kommt das erste Problem: Ein Pod startet nicht mehr. Ein Zertifikat laeuft ab. Ein Node hat kein Disk-Space mehr. Und niemand weiss, was zu tun ist.

Das ist kein hypothetisches Szenario. Die Fluktuation im DevOps-Bereich liegt in Deutschland bei geschaetzten 15-20 Prozent pro Jahr. Bei einer Teamgroesse von einer Person ist das nicht 15 Prozent Risiko -- es ist eine Frage der Zeit.

Die ersten 48 Stunden: Sofortmassnahmen

Sobald die Kuendigung auf dem Tisch liegt, zaehlt jeder Tag. Die Kuendigungsfrist ist Ihre Deadline fuer den Wissenstransfer.

Schritt 1: Bestandsaufnahme der Zugangsdaten

Bevor irgendetwas anderes passiert, muessen alle Zugangsdaten gesichert werden. Klingt offensichtlich, wird aber regelmaessig vergessen.

# Welche Cluster existieren und wo liegen die kubeconfigs?
find /home/ -name "kubeconfig" -o -name ".kube" 2>/dev/null

# Welche Kontexte sind konfiguriert?
kubectl config get-contexts

# Welche Service Accounts haben Admin-Rechte?
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") |
  {name: .metadata.name, subjects: .subjects}'

# Welche Secrets enthalten Zugangsdaten zu externen Systemen?
kubectl get secrets -A -o json | \
  jq '.items[] | select(.type != "kubernetes.io/service-account-token") |
  {namespace: .metadata.namespace, name: .metadata.name, type: .type}'

Sichern Sie diese Informationen in einem Passwort-Manager, auf den mindestens zwei weitere Personen Zugriff haben. Nicht in einer Textdatei auf dem Laptop des Admins.

Schritt 2: Architektur-Dokumentation erzwingen

Wenn keine Dokumentation existiert -- und das ist der Regelfall -- muss der kuendigende Admin sie erstellen. Das ist keine Bitte, sondern Teil der Uebergabepflicht.

Die Mindest-Dokumentation umfasst:

Schritt 3: Runbook-Erstellung priorisieren

Der wichtigste Teil der Dokumentation sind Runbooks fuer die haeufigsten Incidents. Ihr Admin weiss aus dem Gedaechtnis, was bei welchem Alert zu tun ist. Dieses Wissen muss in ausfuehrbare Anleitungen ueberführt werden.

Ein Beispiel fuer ein minimales Runbook:

# runbook-certificate-expiry.yaml
# Dieses Runbook dokumentiert die Schritte bei Zertifikats-Ablauf
---
incident: "Zertifikat laeuft ab / ist abgelaufen"
severity: high
symptoms:
  - "Alert: CertificateExpiringSoon"
  - "HTTPS-Verbindungen schlagen fehl (ERR_CERT_DATE_INVALID)"
  - "Ingress liefert 502 Bad Gateway"

diagnosis:
  - step: "Betroffenes Zertifikat identifizieren"
    command: "kubectl get certificates -A"
  - step: "Zertifikatsstatus pruefen"
    command: "kubectl describe certificate <name> -n <namespace>"
  - step: "Cert-Manager Logs pruefen"
    command: "kubectl logs -n cert-manager deployment/cert-manager --tail=50"

resolution:
  - step: "Cert-Manager Renewal erzwingen"
    command: "kubectl delete secret <tls-secret-name> -n <namespace>"
    note: "Cert-Manager erstellt automatisch ein neues Zertifikat"
  - step: "Warten und verifizieren"
    command: "kubectl get certificate <name> -n <namespace> -w"
    expected: "READY = True innerhalb von 2-5 Minuten"

escalation:
  contact: "Managed Service Provider"
  phone: "+49 ..."
  sla: "Reaktion innerhalb 30 Minuten"

Erstellen Sie Runbooks fuer mindestens diese Szenarien: Node NotReady, Pod CrashLoopBackOff, PVC Pending, Ingress nicht erreichbar, und Zertifikats-Ablauf. Mehr zu typischen Troubleshooting-Szenarien finden Sie im CrashLoopBackOff Troubleshooting Guide.

Die Recruiting-Realitaet im deutschen Markt

Waehrend Sie Wissen sichern, muessen Sie parallel die Nachfolge klaeren. Hier wird es unangenehm.

Warum Recruiting so lange dauert

Das bedeutet: Zwischen dem letzten Tag Ihres alten Admins und dem ersten produktiven Tag des neuen Admins liegen realistisch 3-8 Monate. In dieser Zeit muss jemand den Cluster betreiben.

Kubernetes Engineers mit 3+ Jahren Erfahrung sind im deutschen Markt stark nachgefragt. Die Gehaelter liegen bei 70.000 bis 95.000 Euro brutto jaehrlich, in Muenchen und Frankfurt hoeher. Kleine und mittlere Unternehmen konkurrieren dabei mit Konzernen, die mehr Gehalt und groessere Teams bieten koennen.

Die Freelancer-Option als Zwischenloesung

Manche Unternehmen setzen auf Freelancer, um die Luecke zu ueberbruecken. Das kann funktionieren, hat aber Einschraenkungen:

Ein Freelancer fuer 2-3 Tage pro Woche kostet 6.400 bis 8.400 EUR pro Monat. Dafuer bekommen Sie eine Person, die sich einarbeiten muss und die keine Nacht-Bereitschaft abdeckt. Fuer eine kurzfristige Ueberbrueckung von 4-8 Wochen kann das ausreichen. Fuer laengere Zeitraeume ist ein strukturierter Managed Service wirtschaftlicher.

Die Ueberbrueckungsstrategie: Managed Service als Fallback

Die realistischste Loesung fuer die Uebergangsphase ist ein externer Partner, der den operativen Betrieb uebernimmt. Das ist kein Eingestaendnis von Schwaeche, sondern professionelles Risikomanagement.

Was ein Managed Service Provider in der Uebergangsphase leistet

Ein erfahrener Provider kann typischerweise innerhalb von 1-2 Wochen den Betrieb uebernehmen:

Woche 1: Onboarding und Assessment

• Cluster-Zugang einrichten (kubeconfig, Cloud-Provider-Zugang)
• Bestandsaufnahme: Cluster-Architektur, Workloads, Monitoring-Status
• Kritische Luecken identifizieren (fehlende Backups, abgelaufene Zertifikate, veraltete Kubernetes-Version)

Woche 2: Betriebsuebernahme

• Monitoring und Alerting an das eigene On-Call-System anbinden
• Backup-Strategie verifizieren oder einrichten
• Dokumentation der vorgefundenen Konfiguration
• Erreichbarkeit fuer Incidents herstellen

Ab Woche 3: Regelbetrieb

• 24/7 oder 8/5 Monitoring (je nach SLA)
• Incident Response und Troubleshooting
• Geplante Wartung (Upgrades, Patching)
• Regelmaessige Statusberichte an die IT-Leitung

Details zur Auswahl eines passenden Partners finden Sie im Partner-Auswahlguide.

Kosten der Ueberbrueckung vs. Kosten des Ausfalls

Die Kosten eines ungestuetzten Cluster-Betriebs in der Uebergangsphase sind schwer zu beziffern, aber die Wahrscheinlichkeit eines groesseren Incidents in 6 Monaten ohne Kubernetes-Expertise ist hoch. Allein ein mehrstuendiger Produktionsausfall kann bei einem 500-MA-Unternehmen fuenfstellige Kosten verursachen.

Fuer eine detaillierte Kostenanalyse lesen Sie unseren Managed Service vs. Inhouse Vergleich.

Die Handover-Checkliste

Nutzen Sie diese Checkliste als Grundlage fuer die Uebergabe. Jeder Punkt muss dokumentiert und von einer zweiten Person verifiziert werden.

Zugaenge und Credentials:

• Alle kubeconfig-Dateien gesichert und in Passwort-Manager uebertragen
• Cloud-Provider-Zugaenge (AWS/Azure/GCP Console) dokumentiert
• Container Registry Zugangsdaten gesichert
• DNS-Provider-Zugang dokumentiert
• Monitoring-Tool-Zugaenge (Grafana, PagerDuty, Opsgenie) uebergeben
• VPN-Konfiguration fuer Cluster-Zugang dokumentiert

Cluster-Konfiguration:

• Cluster-Architektur-Diagramm erstellt (Nodes, Namespaces, Services)
• Ingress-Konfiguration und TLS-Zertifikate dokumentiert
• Persistent Volume Claims und Storage-Backends aufgelistet
• Network Policies und Firewall-Regeln beschrieben
• Custom Resource Definitions (CRDs) und Operatoren gelistet

Betriebsprozesse:

• CI/CD-Pipeline-Dokumentation (Trigger, Stages, Rollback)
• Backup-Schedule und Restore-Prozedur getestet
• Monitoring-Alerts und Eskalationspfade dokumentiert
• Runbooks fuer die 10 haeufigsten Incidents erstellt
• Upgrade-Strategie und letzte Upgrade-Historie notiert

Wissenstransfer:

• Mindestens 3 Pair-Sessions mit Nachfolger oder externem Partner durchgefuehrt
• Typische Debugging-Workflows demonstriert
• Bekannte Probleme und Workarounds dokumentiert
• Kontaktdaten fuer Rueckfragen nach Austritt vereinbart

Langfristige Absicherung: Den naechsten Wissensverlust verhindern

Die Kuendigung ist eine Gelegenheit, den Betrieb robuster aufzustellen. Folgende Massnahmen schuetzen langfristig:

Wissen verteilen statt konzentrieren

Das Kernproblem ist nicht die Kuendigung, sondern dass das gesamte Wissen bei einer Person lag. Loesungsansaetze:

• Infrastructure as Code konsequent umsetzen: Wenn die gesamte Cluster-Konfiguration in Git liegt (Terraform, Helm Charts, ArgoCD Application Sets), ist das Wissen im Repository, nicht im Kopf eines Admins. Mehr dazu im GitOps Security Guide.
• Pair-Operations einfuehren: Jede kritische Aenderung am Cluster wird im Vier-Augen-Prinzip durchgefuehrt. Das verlangsamt leicht, baut aber Wissen auf.
• Dokumentation als Definition of Done: Kein Cluster-Change ist fertig, bis er im Runbook aktualisiert ist.

Hybridmodell als optimale Loesung fuer den Mittelstand

Fuer Unternehmen mit 300 bis 1000 Mitarbeitern hat sich ein Hybridmodell bewaehrt: Ein interner Ansprechpartner (muss kein Kubernetes-Spezialist sein) koordiniert mit einem externen Managed Service Provider.

Dieses Modell kostet typischerweise 3.000 bis 6.000 EUR pro Monat und ist damit guenstiger als ein Senior DevOps-Gehalt. Gleichzeitig eliminiert es das Single-Point-of-Failure-Risiko, denn der Provider arbeitet im Team mit Rotation.

Fuer Details zur Absicherung Ihrer Kubernetes-Backups und Disaster Recovery empfehlen wir unseren separaten Guide.

Was Sie heute tun koennen -- auch wenn noch niemand gekuendigt hat

Warten Sie nicht auf die Kuendigung. Pruefen Sie jetzt:

1. Bus-Faktor ermitteln: Wie viele Personen verstehen Ihren Kubernetes-Cluster wirklich? Wenn die Antwort "eine" lautet, handeln Sie.
2. Notfall-Zugang testen: Kann jemand anderes als der Admin auf den Cluster zugreifen? Testen Sie es.
3. Backup-Restore testen: Wann wurde zuletzt ein Restore aus dem Backup getestet? Wenn die Antwort "noch nie" lautet, haben Sie kein Backup, sondern eine Hoffnung.
4. Dokumentationsstand bewerten: Koennte ein externer Engineer mit der vorhandenen Dokumentation den Cluster innerhalb einer Woche uebernehmen?

Falls Sie bei einem oder mehreren Punkten unsicher sind, sprechen Sie mit uns. Wir fuehren Cluster-Assessments durch und erstellen gemeinsam mit Ihrem Team die fehlende Dokumentation -- bevor es brennt. Kontaktieren Sie uns fuer ein unverbindliches Erstgespraech.