Kubernetes Administration auslagern: Wann sich externes Management lohnt

TL;DR: Kubernetes selbst zu betreiben bindet 1,5-3 Vollzeitstellen und kostet ein mittelständisches Unternehmen schnell 300-500k Euro pro Jahr. Externe Administration kann 40-60% günstiger sein und liefert 24/7-Verfügbarkeit, die interne Teams selten abbilden können. Ob sich Outsourcing lohnt, hängt von Teamgrösse, Geschäftskritikalität und Compliance-Anforderungen ab.

Die Realität: Kubernetes ist ein Vollzeit-Job

Kubernetes zu installieren ist nicht das Problem. Das Problem ist der laufende Betrieb: Cluster-Upgrades alle 4 Monate, Security Patches, Certificate Rotation, etcd-Backups, Monitoring, On-Call, Incident Response, Capacity Planning. Für ein kleines Platform-Team mit zwei Leuten bedeutet das: wenig Zeit für die eigentliche Aufgabe, nämlich Entwicklern eine gute Plattform bereitzustellen.

Typische Aufgaben der Kubernetes-Administration:

• Cluster Lifecycle: Upgrades, Patches, Node-Management
• Security: RBAC, Network Policies, Image Scanning, Audit Logging
• Monitoring: Prometheus/Grafana, Alerting, Log-Aggregation
• Backup: etcd-Snapshots, Velero, Disaster Recovery Tests
• Networking: Ingress, DNS, Service Mesh, Load Balancing
• On-Call: 24/7-Bereitschaft für Produktionscluster

Kostenvergleich: Intern vs. Extern

Die folgenden Zahlen basieren auf typischen Szenarien für ein mittelständisches Unternehmen (100-500 Mitarbeiter) mit 2-5 Kubernetes-Clustern.

Interne Administration

Dazu kommen versteckte Kosten: Recruitingkosten (ein Senior Kubernetes Engineer kostet 15-25k in der Vermittlung), Einarbeitungszeit, Wissensverlust bei Fluktuation.

Externe Administration (Managed Service)

Vergleich auf einen Blick

Wann Outsourcing sinnvoll ist

Externe Kubernetes-Administration lohnt sich besonders in diesen Situationen:

Klare Indikatoren für Outsourcing:

• Das Platform-Team hat weniger als 3 Personen
• Kubernetes-Expertise ist nicht die Kernkompetenz des Unternehmens
• 24/7-Betrieb ist notwendig, aber intern nicht darstellbar
• Rekrutierung von Kubernetes-Spezialisten ist schwierig oder dauert zu lange
• Cluster-Upgrades werden regelmässig aufgeschoben
• On-Call-Belastung führt zu Fluktuation

Wann intern sinnvoller ist:

• Grosses, erfahrenes Platform-Team (5+ Personen) vorhanden
• Spezielle Compliance-Anforderungen (z.B. Verschlusssachen)
• Stark angepasste Infrastruktur, die tiefes internes Wissen erfordert
• Kubernetes ist Teil der Kernwertschöpfung (z.B. SaaS-Plattform-Anbieter)

Checkliste: Den richtigen Provider finden

Nicht alle Managed-Service-Anbieter sind gleich. Diese Punkte sollten bei der Evaluierung geprüft werden:

Technische Kompetenz

• Zertifiziertes Kubernetes-Team (CKA, CKS)
• Erfahrung mit der genutzten Cloud-Plattform (AWS EKS, Azure AKS, On-Prem)
• Referenzprojekte in vergleichbarer Grösse und Branche
• Klare Upgrade-Strategie (wie schnell werden neue K8s-Versionen unterstützt?)
• Erfahrung mit relevanten Ecosystem-Tools (Helm, ArgoCD, Istio, Prometheus)

SLA und Support

• Uptime-Garantie mit finanziellen Penalties (nicht nur "best effort")
• Definierte Reaktionszeiten je Severity-Level
• Erreichbarkeit und Sprache des Supports (deutschsprachig?)
• Eskalationspfade dokumentiert
• Regelmässige Service-Reviews (monatlich/quartalsweise)

Compliance und Sicherheit

• Datenverarbeitung in der EU / Deutschland
• Auftragsverarbeitungsvertrag (AVV) nach DSGVO
• ISO 27001-Zertifizierung oder vergleichbar
• Umgang mit Secrets und Zugangsdaten klar geregelt
• Audit-Logs und Nachvollziehbarkeit aller Aktionen

Vertragliches

• Exit-Strategie: Was passiert bei Vertragsende?
• Dokumentation: Wird die Infrastruktur dokumentiert übergeben?
• Lock-in: Proprietäre Tools oder Standard-Tooling?
• Kündigungsfristen und Mindestlaufzeit

Typische SLA-Metriken

Ein professioneller Managed-Kubernetes-Vertrag sollte mindestens diese Metriken abdecken:

Hinweis: Uptime bezieht sich auf die Kubernetes Control Plane, nicht auf die Applikationen darauf. Applikations-Verfügbarkeit ist normalerweise Sache des Kunden.

So läuft die Übergabe typischerweise ab

Phase 1: Assessment (1-2 Wochen)

Der Provider analysiert die bestehende Infrastruktur:

• Cluster-Architektur und Konfiguration
• Bestehende Automatisierung (Terraform, Ansible, etc.)
• Monitoring- und Alerting-Setup
• Backup-Strategie
• Security-Posture (RBAC, Network Policies)
• Compliance-Anforderungen

Phase 2: Onboarding (2-4 Wochen)

Schrittweise Übernahme der operativen Verantwortung:

Woche 1-2: Zugriff einrichten, Dokumentation sichten, Shadow-Betrieb
Woche 3:   Übernahme Monitoring und Alerting, erster On-Call-Einsatz
Woche 4:   Vollständige Betriebsverantwortung, internes Team wird entlastet

Phase 3: Laufender Betrieb

• Regelmässige Cluster-Upgrades nach abgestimmtem Zeitplan
• Proaktives Monitoring und Incident Response
• Monatliche Reports (Verfügbarkeit, Incidents, Changes)
• Quartalsweise Service-Reviews mit Optimierungsvorschlägen

Shared-Responsibility: Wer macht was?

Ein klares Verantwortungsmodell ist entscheidend für eine gute Zusammenarbeit:

Häufige Bedenken -- und realistische Antworten

"Wir verlieren die Kontrolle über unsere Infrastruktur." Ein guter Provider arbeitet transparent. Alle Änderungen sind über GitOps nachvollziehbar, Audit-Logs sind einsehbar, und das interne Team behält Lesezugriff auf alles. Entscheidungen über Architektur und Tooling werden gemeinsam getroffen.

"Was, wenn der Provider ausfällt oder gekündigt wird?" Darum ist die Exit-Strategie so wichtig. Standardisiertes Tooling (Terraform, Helm, ArgoCD) statt proprietärer Lösungen stellt sicher, dass ein Wechsel möglich ist. Die Dokumentation muss vertraglich zugesichert sein.

"Unsere Compliance-Anforderungen sind zu speziell." Die meisten deutschen Managed-Service-Anbieter sind mit DSGVO, BSI-Grundschutz und ISO 27001 vertraut. Für KRITIS-Unternehmen gibt es spezialisierte Provider. Wichtig ist, die Anforderungen vor Vertragsschluss genau zu prüfen.

"Internes Wissen geht verloren." Das Gegenteil ist der Fall: Ein guter Provider dokumentiert die Infrastruktur besser, als es ein unter Zeitdruck stehendes internes Team typischerweise tut. Zudem hat das interne Team mehr Zeit, sich auf Applikationsarchitektur und Developer Experience zu konzentrieren.

Weiterführende Artikel

• Kubernetes Betrieb auslagern
• Kubernetes Support Services
• Kubernetes Monitoring und Observability
• Kubernetes Security Hardening
• Kubernetes Backup und Disaster Recovery

Sie überlegen, Ihre Kubernetes-Administration auszulagern, und suchen einen erfahrenen Partner? Wir bieten Managed Kubernetes Services mit deutschsprachigem 24/7-Support, klaren SLAs und DSGVO-konformer Datenverarbeitung -- Lassen Sie uns über Ihre Anforderungen sprechen.