Kubernetes-Projekt gescheitert: Die 5 haeufigsten Ursachen im Mittelstand

Ihr Kubernetes-Projekt laeuft seit 9 Monaten. Urspruenglich sollte nach 6 Monaten alles in Production sein. Stattdessen: Zwei Cluster in der Staging-Umgebung, die niemand versteht. Ein frustriertes Entwicklerteam. Ein IT-Leiter, der im Vorstand erklaeren muss, warum das Budget schon verbraucht ist, aber nichts live laeuft.

Das ist kein Einzelfall. Die Mehrheit der Kubernetes-Einfuehrungen im deutschen Mittelstand erreicht die gesetzten Ziele nicht im geplanten Zeitrahmen. Dieser Artikel zeigt die fuenf haeufigsten Ursachen, die Warnsignale, die Sie frueh erkennen koennen, und wie Sie ein gescheitertes Projekt noch retten.

TL;DR

• Die haeufigste Ursache fuer gescheiterte Kubernetes-Projekte ist fehlende Betriebskompetenz -- Teams koennen Cluster aufbauen, aber nicht betreiben
• Scope Creep verwandelt ein Migrationsprojekt in ein Plattform-Projekt, das nie fertig wird
• Ohne klare Ownership (wer betreibt den Cluster nach Go-Live?) bleibt Kubernetes ein ewiges Projekt
• Die Warnsignale sind frueh erkennbar: Mehr als 3 Monate ohne Production-Workload ist ein rotes Signal
• Ein gescheitertes Projekt laesst sich retten -- aber nur mit ehrlicher Bestandsaufnahme und reduziertem Scope

Fehler 1: Cluster bauen ohne Betriebskompetenz

Das Muster

Ein motiviertes Team baut einen Kubernetes-Cluster auf. Terraform, ArgoCD, Ingress Controller -- alles funktioniert in der Demo. Dann kommt der Alltag: Zertifikate laufen ab, etcd wird voll, ein Node antwortet nicht mehr. Und niemand weiss, was zu tun ist.

Warum das passiert

Kubernetes aufzusetzen und Kubernetes zu betreiben sind zwei grundlegend verschiedene Disziplinen. Das Aufsetzen ist ein Projekt. Der Betrieb ist ein Dauerzustand, der 24/7 laeuft und Expertise in Monitoring, Incident Response, Security Patching und Capacity Planning erfordert.

Kubernetes-Kompetenz im Mittelstand -- typische Verteilung:

Cluster aufsetzen (Terraform, kubeadm)     ████████████████  80%
Workloads deployen (Helm, kubectl)          ██████████████    70%
Monitoring einrichten (Prometheus, Grafana) ████████████      60%
Incident Response (nachts, am Wochenende)   ████              20%
Security Hardening (NetworkPolicies, PSA)   ████              20%
Upgrade Management (Minor + Patch)          ██████            30%
Backup und Disaster Recovery                ████              20%
Capacity Planning und Cost Optimization     ████              20%

Luecke zwischen "aufbauen" und "betreiben": 40-60 Prozentpunkte

Die Warnsignale

• Cluster steht seit Wochen, aber es gibt kein Alerting
• Kein dokumentierter Prozess fuer Kubernetes-Upgrades
• Niemand kann erklaeren, was bei einem Node-Ausfall automatisch passiert
• Das Wort "Runbook" faellt zum ersten Mal nach dem ersten Ausfall

Die Loesung

Betriebskompetenz entweder aufbauen oder einkaufen. Fuer Mittelstaendler mit 300-1000 Mitarbeitern ist der Aufbau eines eigenen 24/7-Betriebsteams selten wirtschaftlich. Die Alternative: Ein Managed Service, der den Betrieb uebernimmt, waehrend das interne Team sich auf Anwendungsentwicklung konzentriert.

Fehler 2: Scope Creep -- vom Migrationsprojekt zur Plattform

Das Muster

Das Projekt beginnt mit einem klaren Ziel: "Wir migrieren unsere drei wichtigsten Anwendungen auf Kubernetes." Nach 2 Monaten heisst es: "Wir bauen gleich eine interne Developer Platform mit Self-Service Portal, automatischer Pipeline-Erstellung und Multi-Tenancy."

Die Eskalation

Typischer Scope-Creep-Verlauf:

Monat 1:  "3 Anwendungen auf Kubernetes migrieren"
          Aufwand: 3-4 Personenmonate
          ↓
Monat 2:  "Wir brauchen erst eine CI/CD-Pipeline fuer alle Teams"
          Aufwand: +2 Personenmonate
          ↓
Monat 3:  "Multi-Tenancy mit Namespace-Isolation pro Team"
          Aufwand: +3 Personenmonate
          ↓
Monat 4:  "Self-Service Portal, damit Entwickler selbst deployen"
          Aufwand: +4 Personenmonate
          ↓
Monat 5:  "GitOps mit ArgoCD, Policy Engine, Cost Dashboards"
          Aufwand: +3 Personenmonate
          ↓
Monat 6:  "Immer noch nichts in Production."
          Originalbudget: aufgebraucht
          Neuer Zeitplan: unklar
          Motivation: im Keller

Die Warnsignale

• Projektumfang waechst in jedem Statusmeeting
• Kein einziger Production-Workload nach 3 Monaten
• Das Team arbeitet an Tooling statt an Migration
• Saetze wie "Wenn wir schon dabei sind, koennen wir gleich..."

Die Loesung

Zurueck zum Kern. Ein Kubernetes-Projekt im Mittelstand sollte in Phase 1 genau ein Ziel haben: Eine Anwendung in Production auf Kubernetes. Alles andere ist Phase 2, 3, 4.

# projekt-scope-phase1.yaml
# Klare Abgrenzung fuer Phase 1 eines Kubernetes-Projekts

phase_1:
  ziel: "Eine produktive Anwendung auf Kubernetes"
  dauer: "8-12 Wochen"
  scope:
    included:
      - kubernetes_cluster_aufsetzen
      - eine_anwendung_containerisieren
      - ci_cd_pipeline_fuer_diese_anwendung
      - monitoring_und_alerting_basis
      - backup_strategie
      - runbooks_fuer_top_5_incidents
    explicitly_excluded:
      - multi_tenancy
      - self_service_portal
      - plattform_fuer_alle_teams
      - gitops_fuer_alle_repositories
      - cost_optimization_dashboards
  erfolgskriterium: "Anwendung laeuft stabil in Production seit 2 Wochen"
  go_nogo_fuer_phase_2: "Erst nach erreichtem Erfolgskriterium"

Fehler 3: Keine klare Ownership nach Go-Live

Das Muster

Das Projektteam baut den Cluster auf. Das Projektteam migriert die Anwendungen. Dann wird das Projekt "abgeschlossen" und das Projektteam aufgeloest. Zurueck bleibt ein Cluster, fuer den niemand verantwortlich ist.

Wer betreibt den Cluster?

Die Warnsignale

• Das Organigramm zeigt keine Person oder kein Team mit der Rolle "Kubernetes-Betrieb"
• Der Projektplan endet mit "Go-Live" ohne Betriebsuebergabe
• Nach Go-Live sinkt die Aufmerksamkeit fuer den Cluster rapide
• Erste Alerts werden ignoriert, weil unklar ist, wer reagieren soll

Die Loesung

Ownership muss vor dem Projektstart geklaert sein, nicht danach. Drei Modelle funktionieren im Mittelstand:

Ownership-Modelle fuer Kubernetes im Mittelstand:

Modell A: Internes Team
├── 2-3 DevOps Engineers (dediziert oder anteilig)
├── On-Call-Rotation
├── Budget: 180.000 - 280.000 EUR/Jahr (Gehaelter + Tools)
├── Vorteil: Volle Kontrolle
└── Nachteil: Recruiting, Fluktuation, 24/7 schwierig

Modell B: Managed Service
├── Externer Provider uebernimmt Betrieb
├── Interner Ansprechpartner koordiniert
├── Budget: 48.000 - 72.000 EUR/Jahr
├── Vorteil: Sofort verfuegbar, Team-Redundanz
└── Nachteil: Abhaengigkeit vom Provider

Modell C: Hybrid
├── Interner Engineer fuer Day-to-Day
├── Managed Service als Backup und fuer 24/7
├── Budget: 120.000 - 180.000 EUR/Jahr
├── Vorteil: Wissen intern + externe Absicherung
└── Nachteil: Koordinationsaufwand

Details zu den Kosten der verschiedenen Modelle finden Sie im Kostenvergleich intern vs. extern.

Fehler 4: Kubernetes als Selbstzweck statt als Werkzeug

Das Muster

Die Entscheidung fuer Kubernetes faellt aus den falschen Gruenden: "Alle machen das." "Wir muessen Cloud-Native sein." "Das steht in der IT-Strategie." Aber niemand fragt: Welches konkrete Problem loesen wir damit?

Der Realitaetscheck

Kubernetes ist sinnvoll, wenn Sie mindestens eines dieser Probleme haben:

Die Warnsignale

• Kein konkreter Business Case mit messbaren Zielen
• Die Anwendungen sind Monolithen, die auch auf einer VM gut laufen
• Das Team hat weniger als 5 Deployments pro Monat
• Es gibt nur eine Anwendung, die migriert werden soll

Die Loesung

Bevor Sie Kubernetes einfuehren, beantworten Sie drei Fragen:

1. Welches konkrete Problem loesen wir damit (nicht: "Modernisierung", sondern: "Deployment-Zeit von 4 Stunden auf 10 Minuten reduzieren")?
2. Wie messen wir den Erfolg (konkrete KPIs)?
3. Was kostet uns Kubernetes im Betrieb -- und ist das verhaeltnismaessig zum Nutzen?

Mehr zur Komplexitaet von Kubernetes und wann einfachere Loesungen ausreichen, lesen Sie in Kubernetes-Komponenten und Komplexitaet.

Fehler 5: Kein Wissensmanagement -- alles im Kopf einer Person

Das Muster

Ein einzelner Engineer treibt das Kubernetes-Projekt. Er (oder sie) lernt, baut auf, konfiguriert. Nach 6 Monaten kennt eine Person den Cluster in- und auswendig. Alle anderen im Team wissen weniger als am Anfang, weil sie "den Experten" fragen konnten, statt selbst zu lernen.

Was passiert wenn diese Person geht

# Montag: Der Kubernetes-Experte kuendigt

# Was Sie sofort pruefen muessen:
kubectl config get-contexts
# Frage: Wer hat noch Zugang?

kubectl get namespaces
# Frage: Wer weiss, was in jedem Namespace laeuft?

kubectl get secrets -A --no-headers | wc -l
# Frage: Wer kennt die Zugangsdaten zu externen Systemen?

kubectl get cronjobs -A
# Frage: Wer weiss, welcher CronJob was tut und warum?

# Die ehrliche Antwort in den meisten Faellen: Niemand.

Der Bus-Faktor-Test

Machen Sie diesen Test jetzt: Schicken Sie Ihren Kubernetes-Verantwortlichen fuer eine Woche in den Urlaub. Komplett offline. Kein Telefon, keine E-Mail. Was passiert? Wenn die Antwort "Dann haben wir ein Problem" lautet, haben Sie schon jetzt ein Problem.

Die Warnsignale

• Nur eine Person kann Deployments durchfuehren
• Dokumentation existiert nur als "Notizen" auf dem Laptop des Admins
• Bei Incidents wird immer dieselbe Person angerufen
• Andere Teammitglieder sagen: "Da muss man XY fragen"

Die Loesung

Wissensverteilung ist keine Kuer, sondern Ueberlebensstrategie. Konkret bedeutet das:

• Jede Cluster-Aenderung im Vier-Augen-Prinzip (Pull Requests fuer Infrastructure as Code)
• Runbooks fuer alle wiederkehrenden Aufgaben
• Monatliche Wissenstransfer-Sessions (aufgezeichnet)
• Mindestens zwei Personen mit Admin-Zugang und grundlegenden Troubleshooting-Faehigkeiten

Was passiert wenn diese Massnahmen zu spaet kommen, beschreibt der Artikel Kubernetes-Team kuendigt: Was tun?.

Ein gescheitertes Projekt retten: Der 4-Wochen-Plan

Wenn Ihr Kubernetes-Projekt bereits in der Krise ist, hilft kein weiteres Strategiepapier. Es hilft ein konkreter Plan.

Woche 1: Ehrliche Bestandsaufnahme

# Cluster-Assessment: Was existiert tatsaechlich?

echo "=== Cluster-Zustand ==="
kubectl cluster-info
kubectl get nodes -o wide
kubectl version --short

echo ""
echo "=== Workloads in Production ==="
kubectl get deployments -A --field-selector metadata.namespace!=kube-system

echo ""
echo "=== Was laeuft, was nicht ==="
kubectl get pods -A | grep -v Running | grep -v Completed

echo ""
echo "=== Monitoring vorhanden? ==="
kubectl get pods -n monitoring 2>/dev/null || echo "Kein Monitoring-Namespace"

echo ""
echo "=== Backup vorhanden? ==="
kubectl get pods -n velero 2>/dev/null || echo "Kein Velero installiert"

Dokumentieren Sie ehrlich: Was funktioniert, was nicht, was fehlt komplett.

Woche 2: Scope reduzieren

Streichen Sie alles, was nicht fuer den ersten Production-Workload notwendig ist. Kein Self-Service-Portal, kein Multi-Tenancy, kein GitOps fuer alle Teams. Fokus auf eine Anwendung.

Woche 3: Betriebsfaehigkeit herstellen

Installieren Sie das Minimum fuer einen stabilen Betrieb: Monitoring mit Alerting, Backup-Strategie, Runbooks fuer die Top-5-Incidents. Klaeren Sie, wer den Cluster nach Go-Live betreibt.

Woche 4: Erste Anwendung live

Migrieren Sie eine einzelne, unkritische Anwendung. Beweisen Sie, dass es funktioniert. Dann erweitern Sie schrittweise.

Wann Sie ein Projekt aufgeben sollten

Manchmal ist die ehrlichste Entscheidung, ein Projekt zu beenden. Das ist der Fall wenn:

• Das urspruengliche Problem nicht mehr existiert oder sich anders loesen laesst
• Die Kosten fuer die Fertigstellung den erwarteten Nutzen deutlich uebersteigen
• Das Team keine Motivation oder Kompetenz mehr hat und Aufbau unrealistisch ist
• Die Technologie-Entscheidung von Anfang an falsch war

Ein Projekt zu beenden ist kein Scheitern. Ein Projekt ohne Aussicht auf Erfolg weiterzufuehren ist Scheitern.

Fazit

Ein Kubernetes-Projekt scheitert selten an der Technologie. Es scheitert an fehlender Betriebskompetenz, unkontrolliertem Scope, unklarer Ownership, fehlendem Business Case oder konzentriertem Wissen bei einer Person.

Die gute Nachricht: Jedes dieser Probleme ist loesbar. Die Voraussetzung ist eine ehrliche Analyse, warum das Projekt steckt, und die Bereitschaft, den Scope radikal zu reduzieren. Lieber eine Anwendung stabil in Production als zehn Anwendungen auf einem Cluster, den niemand betreiben kann.

Die wichtigste Frage ist nicht "Wie machen wir Kubernetes?", sondern "Wer betreibt Kubernetes -- morgen, naechsten Monat und in zwei Jahren?"

Verwandte Artikel

• Kubernetes Kosten intern vs. extern: Der ehrliche Vergleich
• Kubernetes-Team kuendigt: Was Mittelstaendler jetzt tun muessen
• Kubernetes-Komponenten und Komplexitaet verstehen
• Kubernetes Managed Service vs. Inhouse: Der Kostenvergleich
• Kubernetes 24/7 Betrieb im Mittelstand

Ihr Kubernetes-Projekt steckt fest und Sie brauchen eine ehrliche Einschaetzung? Wir machen ein kostenloses Assessment: Was ist zu retten, was nicht, und wie geht es weiter. Termin vereinbaren.