Managed Kubernetes im Mittelstand: Typische Referenz-Szenarien und was Unternehmen damit erreichen

TL;DR

• Mittelstaendische Unternehmen wechseln zu Managed Kubernetes typischerweise aus drei Gruenden: Kuendigung des einzigen Admins, wachsende Compliance-Anforderungen oder gescheiterte Self-Managed-Versuche.
• Die typische Vorher-Situation: 1-2 Admins, keine 24/7-Abdeckung, undokumentierte Cluster-Konfiguration, Angst vor Kubernetes-Upgrades.
• Nachher: 99,9% Verfuegbarkeit, dokumentierte Prozesse, regelmaessige Upgrades und ein Team statt einer Einzelperson.
• Die Transition dauert typischerweise 4 bis 8 Wochen fuer bestehende Cluster, inklusive Dokumentation und Wissenstransfer.
• Der haeufigste Fehler: Zu lange warten, bis der einzige Admin kuendigt und das Wissen weg ist.

Warum Referenz-Szenarien statt Hochglanz-Case-Studies

Dieser Artikel beschreibt typische Situationen, die wir im deutschen Mittelstand immer wieder sehen. Keine erfundenen Firmennamen, keine geschoenten Zahlen. Stattdessen: realistische Muster, die sich aus hunderten Gespraechen mit IT-Leitern und DevOps-Teams ergeben.

Wenn Sie sich in einem dieser Szenarien wiedererkennen, sind Sie nicht allein. Die Probleme sind strukturell -- und die Loesungen entsprechend uebertragbar.

Szenario 1: Der Admin kuendigt -- und nimmt das Wissen mit

Typische Ausgangslage

Ein Industrieunternehmen mit circa 500 Mitarbeitern betreibt seit zwei Jahren Kubernetes auf Azure AKS. Die gesamte E-Commerce-Plattform und mehrere interne Tools laufen auf zwei Clustern. Ein einziger Senior DevOps-Engineer hat die Cluster aufgebaut und betreut sie im Tagesgeschaeft.

Dann kuendigt der Admin. Drei Monate Kuendigungsfrist, aber die Uebergabe ist duenn: Die Cluster-Konfiguration ist teilweise in Terraform abgebildet, teilweise manuell per kubectl konfiguriert. Monitoring laeuft, aber niemand weiss, wo die Alert-Regeln definiert sind. Backups existieren, wurden aber nie getestet.

Was die IT-Leitung realisiert

Wissensverlust-Analyse nach Kuendigung des Kubernetes-Admins:

Dokumentiert:
  - Terraform-Module fuer Basis-Infrastruktur     [vorhanden]
  - Deployment-Pipelines in GitLab CI              [vorhanden]
  - Grundlegendes Architektur-Diagramm             [veraltet]

Nicht dokumentiert:
  - Custom Prometheus Alert Rules                  [nur im Cluster]
  - Network Policy Ausnahmen                       [kubectl apply, nicht in Git]
  - Workarounds fuer bekannte Probleme             [im Kopf des Admins]
  - Backup-Restore-Prozedur                        [nie getestet]
  - Eskalationspfade bei Nacht-Ausfaellen          [gab es nicht]
  - Secrets-Rotation-Prozess                       [manuell, undokumentiert]

Typischer Loesungsweg

1. Woche 1-2: Managed-Service-Anbieter fuehrt Cluster-Assessment durch. Dokumentation aller bestehenden Konfigurationen, Identifikation von Risiken.
2. Woche 3-4: Paralleler Wissenstransfer vom kuendigenden Admin an den Managed-Service-Partner. Alles, was nicht in Git liegt, wird in Infrastructure-as-Code ueberfuehrt.
3. Woche 5-6: Uebernahme des operativen Betriebs. Monitoring wird konsolidiert, fehlende Alerts nachgezogen.
4. Woche 7-8: Backup-Restore-Test, Dokumentation der Runbooks, Uebergabe an das interne Team.

Typische Ergebnisse nach 3 Monaten

Warum ein einzelner Admin keine 24/7-Abdeckung liefern kann, erklaert unser Artikel zum 24/7-Betrieb im Mittelstand.

Szenario 2: Compliance-Druck erzwingt professionellen Betrieb

Typische Ausgangslage

Ein SaaS-Anbieter mit 350 Mitarbeitern betreibt seine Plattform auf Kubernetes. Bisher war der Betrieb pragmatisch: "Es laeuft, wir fassen es nicht an." Dann kommt ein grosser Enterprise-Kunde, der vor Vertragsabschluss einen Security-Fragebogen schickt. 140 Fragen zu Themen wie:

• Wie ist die Zugriffskontrolle auf Produktions-Cluster geregelt?
• Gibt es auditierbare Logs aller administrativen Zugriffe?
• Wie oft werden Kubernetes-Upgrades durchgefuehrt?
• Welche Vulnerability-Scanning-Prozesse sind implementiert?
• Existiert ein dokumentierter Disaster-Recovery-Plan?

Das interne Team kann 30 der 140 Fragen beantworten. Der Rest ist entweder nicht implementiert oder nicht dokumentiert.

Was das in der Praxis bedeutet

Compliance-Gap-Analyse (typisches Ergebnis):

Zugriffskontrolle:
  [x] RBAC aktiviert
  [ ] Least-Privilege umgesetzt (zu viele cluster-admin Bindings)
  [ ] ServiceAccount-Tokens rotiert
  [ ] Break-Glass-Prozedur dokumentiert

Audit und Logging:
  [x] Application Logs vorhanden
  [ ] Kubernetes API Audit Logs aktiviert
  [ ] Log-Retention Policy definiert
  [ ] Tamper-Proof Log Storage

Vulnerability Management:
  [x] Docker Images aus eigener Registry
  [ ] Automatisches Image Scanning
  [ ] Policy: Keine Images mit Critical CVEs in Production
  [ ] Regelmaessige Base Image Updates

Disaster Recovery:
  [x] etcd Backups (automatisch durch Cloud Provider)
  [ ] Application-Level Backups
  [ ] Dokumentierter Recovery-Prozess
  [ ] Recovery Time Objective definiert
  [ ] DR-Test durchgefuehrt

Typischer Loesungsweg

Der Managed-Service-Partner schliesst die Luecken systematisch. Dabei wird nicht alles gleichzeitig umgesetzt, sondern priorisiert: Zuerst das, was der Enterprise-Kunde im Fragebogen verlangt. Dann der Rest.

Typische Priorisierung:

1. Sofort (Woche 1-2): Audit Logging aktivieren, RBAC bereinigen, Image Scanning einrichten
2. Kurzfristig (Woche 3-4): Network Policies, Backup-Strategie dokumentieren, DR-Plan erstellen
3. Mittelfristig (Monat 2-3): Compliance-Dashboards, automatisierte Policy-Checks, Schulung internes Team

Typische Ergebnisse nach 3 Monaten

Wie Sie Kubernetes-Compliance ohne eigenes Security-Team erreichen, zeigt unser Compliance-Guide.

Szenario 3: Self-Managed Kubernetes wird zu komplex

Typische Ausgangslage

Ein Logistik-Unternehmen mit 700 Mitarbeitern hat vor drei Jahren mit Kubernetes angefangen. Zwei DevOps-Engineers haben den Cluster auf AWS EKS aufgebaut. Anfangs lief alles gut: 5 Microservices, ein Cluster, ueberschaubarer Betrieb.

Drei Jahre spaeter sieht die Realitaet anders aus:

Aktuelle Cluster-Komplexitaet:

Cluster:                    3 (Dev, Staging, Production)
Microservices:              38
Namespaces:                 12
Helm Charts:                24 (davon 8 Custom, 16 Community)
CRDs installiert:           47
Prometheus Alert Rules:     156
CI/CD Pipelines:            38

Beteiligte Teams:           4 Entwicklungsteams
Deployments pro Woche:      ~25-30
Incidents pro Monat:        6-10 (davon 2-3 nachts)

Die beiden DevOps-Engineers sind ueberlastet. Kubernetes-Upgrades werden aufgeschoben, weil niemand die Zeit hat, alle 24 Helm Charts auf Kompatibilitaet zu pruefen. Security-Patches werden verspaetet eingespielt. Neue Features von den Entwicklungsteams werden blockiert, weil die Pipeline-Kapazitaet fehlt.

Die Kipp-Punkt-Analyse

Es gibt einen typischen Kipp-Punkt, ab dem Self-Managed-Kubernetes im Mittelstand kippt:

Typischer Loesungsweg

Bei diesem Szenario uebernimmt der Managed-Service-Partner schrittweise:

1. Phase 1 (Monat 1): Production-Cluster wird uebernommen. On-Call geht an den Partner.
2. Phase 2 (Monat 2): Staging-Cluster-Uebernahme. Aufgeschobene Kubernetes-Upgrades werden nachgeholt.
3. Phase 3 (Monat 3): Dev-Cluster wird angebunden. Interne Engineers koennen sich auf Plattform-Entwicklung konzentrieren statt auf Betrieb.

Typische Ergebnisse nach 6 Monaten

Fuer den vollstaendigen Vergleich der Optionen lesen Sie unseren Artikel Freelancer vs. Managed Service.

Die drei haeufigsten Trigger fuer den Wechsel

Aus allen Szenarien kristallisieren sich drei wiederkehrende Muster heraus:

Trigger 1: Personalrisiko (45% der Faelle)

Der haeufigste Anlass ist personalbedingt: Kuendigung, Burnout oder geplanter Ruhestand des Kubernetes-Admins. Mittelstaendler realisieren erst dann, wie abhaengig sie von einer einzelnen Person sind.

Trigger 2: Compliance-Anforderungen (30% der Faelle)

Ein Audit steht an, ein grosser Kunde verlangt Nachweise, oder neue Regulierung (NIS2, DORA, branchenspezifische Vorgaben) macht professionellen Betrieb zur Pflicht. Mehr dazu in unserem DSGVO- und BSI-Compliance-Guide.

Trigger 3: Skalierungsgrenzen (25% der Faelle)

Die Cluster-Komplexitaet waechst ueber das hinaus, was das interne Team leisten kann. Aufgeschobene Upgrades, steigende Incident-Zahlen und Entwickler-Frustration sind die Symptome.

Was die Transition in der Praxis kostet

Einmalige Transitionskosten

Typische Transitionskosten (Bestandscluster):

Cluster-Assessment und Dokumentation:     2.000 -  5.000 EUR
Wissenstransfer und Runbook-Erstellung:   3.000 -  8.000 EUR
Monitoring-Setup und Integration:         1.500 -  4.000 EUR
Backup-Strategie und erster DR-Test:      1.000 -  3.000 EUR
Kubernetes-Upgrade (wenn notwendig):      2.000 -  6.000 EUR
───────────────────────────────────────────────────────────────
Gesamt Transition:                        9.500 - 26.000 EUR

Typische Greenfield-Kosten (neuer Cluster):

Cluster-Design und Aufbau:               5.000 - 15.000 EUR
CI/CD-Pipeline-Integration:              3.000 -  8.000 EUR
Monitoring, Logging, Alerting:           2.000 -  5.000 EUR
Security-Baseline und Policies:          2.000 -  5.000 EUR
Dokumentation und Schulung:              2.000 -  4.000 EUR
───────────────────────────────────────────────────────────────
Gesamt Greenfield:                      14.000 - 37.000 EUR

Laufende Kosten

Die laufenden Kosten fuer Managed Kubernetes liegen typischerweise zwischen 3.000 und 5.000 EUR pro Monat, abhaengig vom Leistungsumfang. Eine detaillierte Aufschluesselung finden Sie in unserem Artikel Kubernetes Kosten intern vs. extern.

Checkliste: Ist Managed Kubernetes das Richtige fuer Sie?

Beantworten Sie diese Fragen ehrlich:

• Haben Sie mehr als eine Person, die Ihren Kubernetes-Cluster versteht und betreiben kann?
• Kann Ihr Team nachts und am Wochenende auf Ausfaelle reagieren?
• Sind Ihre Cluster-Konfigurationen vollstaendig in Git versioniert?
• Fuehren Sie Kubernetes-Upgrades regelmaessig (mindestens 2x pro Jahr) durch?
• Haben Sie einen getesteten Disaster-Recovery-Plan?
• Koennen Sie einen Compliance-Fragebogen mit 100+ Fragen zur Kubernetes-Infrastruktur beantworten?

Wenn Sie mehr als zwei dieser Fragen mit "Nein" beantworten, ist ein Managed Service wahrscheinlich die bessere Option.

Fazit: Die Muster sind eindeutig

Die drei Szenarien in diesem Artikel sind keine Einzelfaelle. Es sind die drei haeufigsten Situationen, in denen mittelstaendische Unternehmen zu Managed Kubernetes wechseln. Der gemeinsame Nenner: Der Wechsel passiert fast immer reaktiv -- nach einer Kuendigung, einem gescheiterten Audit oder einem naechtlichen Ausfall, der zu lange gedauert hat.

Die Unternehmen, die proaktiv wechseln, bevor einer dieser Trigger eintritt, sparen sich den Stress, die Uebergangsluecken und die damit verbundenen Kosten.

Fuer eine strukturierte Partnerwahl nutzen Sie unseren Auswahl-Guide fuer Kubernetes-Partner in Deutschland.