Managed Kubernetes fuer den Mittelstand: Wann lohnt sich Outsourcing wirklich?

TL;DR

• Managed Kubernetes (KaaS) rechnet sich ab ca. 3 Clustern oder wenn das Team weniger als 2 dedizierte Kubernetes-Engineers hat
• Der groesste Kostenfaktor ist nicht die Infrastruktur, sondern der 24/7-Betrieb: On-Call, Upgrades, Security Patches
• Entscheidend ist die Abgrenzung der Verantwortlichkeiten: Control Plane vs. Worker Nodes vs. Application Layer
• DSGVO-Konformitaet laesst sich ueber AVV und Rechenzentrumsstandort vertraglich absichern
• Ein Proof-of-Concept mit einer nicht-kritischen Workload sollte immer der erste Schritt sein

Das eigentliche Problem: Kubernetes-Betrieb skaliert nicht linear

Viele Teams unterschaetzen den Betriebsaufwand fuer Kubernetes. Die initiale Einrichtung eines Clusters ist heute mit Tools wie kubeadm, kOps oder Cluster API relativ einfach. Der Aufwand steckt im laufenden Betrieb.

Ein typisches Szenario: Das Team baut einen Cluster auf, alles laeuft. Dann kommt das erste Minor-Upgrade, der erste etcd-Ausfall um 3 Uhr nachts, die erste CVE in der Container Runtime. Ploetzlich braucht man Runbooks, On-Call-Rotationen und tiefes Wissen ueber etcd-Konsistenz.

Der Betrieb eines produktiven Kubernetes-Clusters erfordert Expertise in mindestens sechs Bereichen gleichzeitig: Netzwerk (CNI, Service Mesh, Ingress), Storage (CSI, Backup), Security (RBAC, Pod Security, Image Scanning), Observability (Metrics, Logs, Traces), Upgrades (Control Plane, Nodes, Add-ons) und Disaster Recovery.

Managed vs. Self-Hosted: Ein ehrlicher Vergleich

Bevor man eine Entscheidung trifft, sollte man die tatsaechlichen Unterschiede verstehen. Die folgende Tabelle zeigt, wo die Verantwortung jeweils liegt.

Die Kernfrage ist nicht ob man Kubernetes kann, sondern ob man es 24/7/365 betreiben will.

Architektur: Was ein guter Managed Service abdeckt

Ein solider Managed-Kubernetes-Service besteht aus mehreren Schichten. Das folgende Deployment zeigt eine typische Anwendung, die auf einem KaaS-Cluster laeuft. Der Kunde liefert nur das Manifest, der Provider kuemmert sich um alles darunter.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-api
  namespace: production
  labels:
    app: backend-api
    team: platform
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: backend-api
  template:
    metadata:
      labels:
        app: backend-api
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: topology.kubernetes.io/zone
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: backend-api
      containers:
      - name: api
        image: registry.example.de/backend-api:2.4.1
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "250m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /livez
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20

Beachtenswert ist hier die topologySpreadConstraints-Konfiguration. Sie verteilt Pods ueber Availability Zones, was bei Managed Services oft automatisch unterstuetzt wird, weil der Provider die Node-Topology bereits korrekt gelabelt hat.

Kostenrechnung: Self-Hosted vs. Managed

Die ehrliche Kostenrechnung ist oft ueberraschend. Viele Teams rechnen nur die Infrastrukturkosten, vergessen aber die Personalkosten.

Die Infrastrukturkosten sind beim Managed Service etwas hoeher (Provider-Marge). Aber der Wegfall der dedizierten Engineers und der On-Call-Rotation macht den Unterschied. Mehr zur TCO-Analyse unter Kubernetes Hosting Kosten 2025: Cloud vs On-Premise.

Terraform-Beispiel: Managed Cluster provisionieren

Die meisten KaaS-Anbieter lassen sich per Terraform provisionieren. Hier ein vereinfachtes Beispiel fuer einen Managed Cluster mit dedizierten Node Pools:

resource "managed_kubernetes_cluster" "production" {
  name               = "prod-cluster-01"
  kubernetes_version  = "1.29"
  region             = "eu-de-1"

  control_plane {
    high_availability = true
  }

  default_node_pool {
    name       = "system"
    node_count = 3
    vm_size    = "s-4vcpu-8gb"
    zones      = ["eu-de-1a", "eu-de-1b", "eu-de-1c"]
  }

  tags = {
    environment = "production"
    team        = "platform"
    compliance  = "dsgvo"
  }
}

resource "managed_kubernetes_node_pool" "workloads" {
  cluster_id = managed_kubernetes_cluster.production.id
  name       = "workloads"
  node_count = 5
  vm_size    = "s-8vcpu-16gb"
  zones      = ["eu-de-1a", "eu-de-1b", "eu-de-1c"]

  auto_scaling {
    enabled   = true
    min_count = 3
    max_count = 10
  }

  labels = {
    workload-type = "application"
  }
}

Der entscheidende Vorteil: high_availability = true fuer den Control Plane. Bei Self-Hosted muesste man hier manuell ein Multi-Master-Setup mit etcd-Quorum konfigurieren, was erheblichen Aufwand bedeutet.

DSGVO: Worauf es vertraglich ankommt

Fuer den Betrieb in der EU ist die DSGVO-Konformitaet keine Option, sondern Pflicht. Die wichtigsten Punkte bei der Provider-Auswahl:

Auftragsverarbeitungsvertrag (AVV): Muss vor Vertragsschluss vorliegen. Der AVV regelt, welche Daten der Provider verarbeitet und welche technischen und organisatorischen Massnahmen (TOMs) er implementiert. Ohne AVV kein Managed Service.

Rechenzentrumsstandort: Daten muessen in EU-Rechenzentren verarbeitet werden. Idealerweise bietet der Provider Standorte in Deutschland an. Wichtig: Auch die Backup-Ziele und Monitoring-Daten muessen innerhalb der EU bleiben.

Zugriffskontrollen: Der Provider braucht Zugang zum Cluster fuer den Betrieb. Dieser Zugang muss auditierbar, zeitlich begrenzt und nach dem Least-Privilege-Prinzip gestaltet sein. Break-Glass-Prozeduren sollten dokumentiert sein.

Weitere Details zur Compliance-Absicherung finden sich unter DSGVO und Kubernetes Compliance.

Entscheidungsmatrix: Managed oder Self-Hosted?

Nicht jedes Team sollte auf Managed setzen. Hier eine pragmatische Entscheidungshilfe:

Managed KaaS ist die bessere Wahl, wenn:

• Das Team weniger als 2 dedizierte Kubernetes-Engineers hat
• Mehr als 2 produktive Cluster betrieben werden
• 24/7-Verfuegbarkeit gefordert ist, aber kein On-Call-Team existiert
• Die Kernkompetenz in der Anwendungsentwicklung liegt, nicht im Infrastrukturbetrieb
• Compliance-Anforderungen (DSGVO, ISO 27001) ohne eigenes Security-Team erfuellt werden muessen

Self-Hosted ist sinnvoll, wenn:

• Spezielle Anforderungen an die Infrastruktur bestehen (Bare-Metal, GPU-Cluster, Air-Gapped)
• Ein erfahrenes Platform-Engineering-Team vorhanden ist
• Volle Kontrolle ueber den Control Plane noetig ist (z.B. Custom Admission Controllers)
• Regulatorische Anforderungen ein Self-Hosted-Modell vorschreiben

Migration: Der pragmatische Weg

Eine Migration zu einem Managed Service sollte schrittweise erfolgen. Dieser Dreischritt hat sich bewaehrt:

Phase 1 (Woche 1-4): Proof of Concept. Eine nicht-kritische Anwendung wird auf dem Managed Cluster deployed. Das Team lernt die Schnittstellen, testet CI/CD-Integration und validiert Monitoring. Parallel wird der AVV verhandelt.

Phase 2 (Woche 5-8): Pilot mit echtem Traffic. Ein weniger kritischer Service wird migriert und traegt echten Produktions-Traffic. Hier zeigen sich die realen SLA-Werte des Providers. Alerting und Incident-Response-Prozesse werden integriert.

Phase 3 (Woche 9-12): Rollout kritischer Workloads. Nach validierten Erfahrungen aus Phase 1 und 2 werden geschaeftskritische Services migriert. Rollback-Plaene sind fuer jeden Service dokumentiert. Ein detaillierter Ansatz zur Produktionsvorbereitung steht unter Kubernetes Cluster Setup fuer Production.

Monitoring: Was der Provider liefert vs. was man selbst braucht

Ein haeufiger Irrtum: Der Managed-Service-Provider ueberwacht alles. In der Realitaet ueberwacht der Provider die Infrastruktur-Ebene (Node-Health, Control-Plane-Verfuegbarkeit, etcd-Latenz). Die Applikations-Ebene bleibt beim Kunden.

Fuer ein vollstaendiges Observability-Setup braucht man beides. Der Provider liefert Cluster-Metriken, das eigene Team baut Application-Dashboards und Business-KPIs darauf auf. Wie man ein effektives Monitoring aufbaut, beschreibt unser Guide zu Kubernetes Monitoring mit Open Source.

Typische Provider-SLAs:

Haeufige Fehler bei der Provider-Auswahl

Nur auf den Preis schauen. Der guenstigste Provider spart am Support. Wenn um 2 Uhr nachts etcd ausfaellt, zaehlt die Reaktionszeit, nicht der Monatspreis.

Lock-In unterschaetzen. Manche Provider nutzen proprietaere Add-ons oder Custom Resource Definitions. Fragen Sie vor Vertragsschluss, wie ein Exit aussieht und ob Standard-Kubernetes-APIs verwendet werden.

Shared Responsibility nicht klaeren. Der haeufigste Konfliktpunkt: Wer ist fuer Netzwerk-Policies zustaendig? Wer konfiguriert den Ingress Controller? Ein klares Responsibility-Matrix-Dokument (RACI) ist Pflicht.

Backup-Strategie nicht testen. Der Provider sichert den Cluster-State. Aber wer sichert die Persistent Volumes? Und wurde der Restore jemals getestet? Ein ungetestetes Backup ist kein Backup. Mehr dazu unter Kubernetes Backup und Disaster Recovery.

Fazit

Managed Kubernetes ist kein Zeichen von Schwaeche, sondern eine strategische Entscheidung. Die Frage ist nicht ob man Kubernetes kann, sondern wo man seine begrenzten Engineering-Ressourcen am besten einsetzt: im Infrastrukturbetrieb oder in der Produktentwicklung.

Fuer die meisten mittelstaendischen Teams ist die Antwort klar: Applikationen bauen statt Cluster warten.

Wer konkret evaluieren moechte, ob Managed Kubernetes fuer das eigene Setup sinnvoll ist, kann sich gerne bei uns melden. In einem kurzen Gespraech klaeren wir die technischen Rahmenbedingungen und schaetzen den Aufwand realistisch ein: Kontakt aufnehmen.