Kubernetes-Betrieb auslagern oder selbst machen? Eine ehrliche Entscheidungshilfe

TL;DR

• Der Eigenbetrieb eines produktionsreifen Kubernetes-Clusters erfordert mindestens 1.5-2 FTE an dedizierter Ops-Kapazitaet -- das unterschaetzen die meisten Teams
• Managed Kubernetes (EKS, AKS, GKE) nimmt Ihnen die Control Plane ab, aber nicht das Node-Management, Monitoring, Security oder Application Operations
• "Fully Managed"-Angebote spezialisierter Provider decken mehr ab, kosten aber typischerweise 2.000-8.000 EUR/Monat zusaetzlich zu den Infrastrukturkosten
• Die Break-Even-Rechnung kippt meistens bei 3+ Clustern oder wenn Ihr Team unter 5 Engineers hat zugunsten von Managed Services
• Mischen ist moeglich und oft sinnvoll: Managed Control Plane plus internes Application-Operations

Die Frage, die alle falsch stellen

Die meisten Teams stellen die Frage so: "Sollen wir unseren Kubernetes-Betrieb auslagern?" Das impliziert eine binaere Entscheidung -- alles selbst machen oder alles abgeben. In der Praxis gibt es aber ein Spektrum mit mindestens vier Stufen:

Stufe 1: Self-Managed (alles selbst) Sie betreiben die komplette Infrastruktur. Bare Metal oder VMs, kubeadm oder k3s, etcd-Backups, Control-Plane-HA, Node-Autoscaling, das volle Programm. Sie brauchen tiefes Linux-, Netzwerk- und Kubernetes-Wissen im Team.

Stufe 2: Managed Control Plane (EKS, AKS, GKE) Der Cloud-Provider betreibt die Control Plane (API-Server, etcd, Scheduler, Controller-Manager). Sie kuemmern sich um Worker Nodes, Netzwerk-Konfiguration, Monitoring, Deployments und Security. Das ist die heute haeufigste Variante.

Stufe 3: Managed Platform (spezialisierte Anbieter) Ein Dienstleister uebernimmt zusaetzlich zur Control Plane auch Node-Management, Monitoring, Alerting, Backup und Basis-Security. Ihr Team fokussiert sich auf Application-Deployment und -Konfiguration.

Stufe 4: Fully Managed (Application-Level) Der Provider betreibt nicht nur die Infrastruktur, sondern kuemmert sich auch um Deployments, Rollbacks, Performance-Tuning und Incident Response auf Applikationsebene. Ihr Team definiert nur noch "was" deployt wird, nicht "wie".

Die meisten KMU landen bei Stufe 2 oder 3. Stufe 1 ist fuer Teams sinnvoll, die Kubernetes als Kernkompetenz aufbauen wollen. Stufe 4 ist selten und teuer, aber fuer kleine Teams mit geschaeftskritischen Anwendungen manchmal die richtige Wahl.

Die echten Kosten: Was Eigenbetrieb wirklich kostet

Lassen Sie uns ehrlich rechnen. Nicht mit "bis zu X% Einsparung", sondern mit konkreten Posten.

Szenario: 3 Cluster (Dev, Staging, Prod), je 5-10 Nodes

Personalkosten (Eigenbetrieb):

Infrastrukturkosten (Cloud-basiert, Eigenmanagement):

Total Eigenbetrieb: ca. 216.000 EUR/Jahr

Dasselbe Szenario als Managed Service

Managed Control Plane (z.B. EKS/AKS/GKE):

Personalkosten (reduziert):

Managed Platform Add-on (Stufe 3): Wenn Sie zusaetzlich einen spezialisierten Anbieter fuer Node-Management und Security beauftragen: ca. 3.000-5.000 EUR/Monat = 36.000-60.000 EUR/Jahr.

Total Managed (Stufe 2): ca. 87.120 EUR/Jahr Total Managed (Stufe 3): ca. 123.120-147.120 EUR/Jahr

Die Differenz zwischen Eigenbetrieb und Managed Service (Stufe 2) liegt bei ca. 130.000 EUR/Jahr. Selbst bei Stufe 3 sparen Sie noch 70.000-90.000 EUR. Das ist die Realitaet, wenn man Personalkosten ehrlich einrechnet.

Was ein Managed Service nicht abnimmt

Ein verbreitetes Missverstaendnis: "Managed Kubernetes heisst, ich muss mich um nichts kuemmern." Das stimmt nicht. Auch mit EKS/AKS/GKE bleibt bei Ihnen:

• Application Deployment: Ihre Deployments, Services, Ingresses, ConfigMaps schreiben und pflegen
• Resource Management: CPU/Memory Requests und Limits setzen und tunen
• Application Monitoring: Business-Metriken, Application-Level-Alerts
• Secret Management: Vault-Integration, Secret-Rotation
• RBAC-Konfiguration: Wer darf was in welchem Namespace?
• Network Policies: Netzwerksegmentierung auf Pod-Ebene
• CI/CD-Pipelines: Build, Test, Deploy Ihrer Anwendungen
• Kapazitaetsplanung: Wann brauchen Sie mehr Nodes?

Der Managed Service nimmt Ihnen die "undankbare" Arbeit ab (etcd-Backups, Control-Plane-Upgrades, Node-OS-Patches), aber die fachliche Arbeit bleibt bei Ihnen. Detaillierte Informationen zu Ressourcenplanung finden Sie unter Kubernetes Capacity Planning.

Entscheidungskriterien: Wann was passt

Eigenbetrieb ist sinnvoll, wenn:

• Sie Kubernetes als strategische Kernkompetenz aufbauen wollen (z.B. als Plattform-Team fuer ein grosses Entwicklungsteam)
• Sie regulatorische Anforderungen haben, die einen externen Provider ausschliessen (selten, aber kommt vor in bestimmten Branchen)
• Sie Bare-Metal-Infrastruktur nutzen und keine Cloud-Abhaengigkeit wollen
• Sie ein erfahrenes Ops-Team mit 3+ Kubernetes-erfahrenen Engineers haben

Managed Service ist sinnvoll, wenn:

• Ihr Ops-Team kleiner als 3 Personen ist
• Kubernetes Mittel zum Zweck ist, nicht Ihr Kernprodukt
• Sie schnell produktionsreif sein muessen (Wochen statt Monate)
• On-Call-Rotation fuer Infrastruktur nicht intern abbildbar ist

Praxistest: Eine Frage, die hilft

Stellen Sie Ihrem Team diese Frage: "Wenn um 3 Uhr nachts der etcd-Cluster korrupt ist -- wie lange brauchen wir, um ihn wiederherzustellen?"

Wenn die Antwort "Kein Problem, haben wir schon gemacht, dauert 20 Minuten" lautet, koennen Sie Eigenbetrieb verantworten. Wenn die Antwort "Aehm..." ist, sollten Sie zumindest die Control Plane auslagern.

Terraform-Beispiel: Managed Cluster aufsetzen

Falls Sie sich fuer den Managed-Weg entscheiden, hier ein Terraform-Beispiel fuer einen AKS-Cluster:

resource "azurerm_kubernetes_cluster" "production" {
  name                = "prod-cluster"
  location            = "germanywestcentral"
  resource_group_name = azurerm_resource_group.k8s.name
  dns_prefix          = "prod"
  kubernetes_version  = "1.30"

  default_node_pool {
    name                = "system"
    vm_size             = "Standard_D4s_v5"
    min_count           = 2
    max_count           = 5
    enable_auto_scaling = true

    upgrade_settings {
      max_surge = "33%"
    }
  }

  identity {
    type = "SystemAssigned"
  }

  network_profile {
    network_plugin    = "azure"
    network_policy    = "calico"
    load_balancer_sku = "standard"
  }

  maintenance_window {
    allowed {
      day   = "Sunday"
      hours = [2, 3, 4]
    }
  }

  tags = {
    environment = "production"
    managed_by  = "terraform"
  }
}

Beachten Sie network_policy = "calico" -- ohne Network-Policy-Enforcement ist Ihre Netzwerksegmentierung wertlos. Und maintenance_window stellt sicher, dass automatische Upgrades nicht waehrend der Geschaeftszeiten passieren. Der Standort germanywestcentral platziert den Cluster in der Azure-Region Frankfurt. Mehr zum Thema Kosten und Hosting finden Sie unter Kubernetes Hosting Kosten im Vergleich.

Monitoring-Setup: Was Sie in jedem Fall brauchen

Egal ob Eigen- oder Managed-Betrieb, ein Monitoring-Stack ist nicht optional. Hier eine minimale Kube-Prometheus-Stack-Konfiguration via Helm:

# Kube-Prometheus-Stack installieren (beinhaltet Prometheus, Grafana, Alertmanager)
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set prometheus.prometheusSpec.retention=14d \
  --set prometheus.prometheusSpec.storageSpec.volumeClaimTemplate.spec.resources.requests.storage=50Gi \
  --set grafana.adminPassword="$(openssl rand -base64 24)" \
  --set alertmanager.alertmanagerSpec.storage.volumeClaimTemplate.spec.resources.requests.storage=10Gi \
  --set prometheus.prometheusSpec.resources.requests.memory=2Gi \
  --set prometheus.prometheusSpec.resources.limits.memory=4Gi

# Pruefe, ob alle Pods laufen
kubectl get pods -n monitoring

14 Tage Retention sind fuer die meisten Teams ein guter Startpunkt. Fuer laengerfristiges Storage koennen Sie Thanos oder Mimir als Remote-Write-Ziel konfigurieren. Detaillierte Anleitungen zum Monitoring-Stack finden Sie unter Kubernetes Observability Stack.

Risiken bei der Auslagerung

Managed Services sind kein Allheilmittel. Diese Risiken sollten Sie kennen:

Vendor Lock-in: Je mehr Managed Services Sie nutzen (nicht nur K8s, sondern auch Datenbanken, Queues, Identity), desto schwieriger wird ein Provider-Wechsel. Halten Sie Ihre Workload-Definitionen portabel -- Standard-Kubernetes-APIs, keine proprietaeren CRDs.

Kontrollverlust bei Incidents: Wenn der Managed-Provider ein Problem hat, warten Sie. Sie koennen nicht selbst in die Control Plane eingreifen. Stellen Sie sicher, dass Ihr SLA klar definiert, wie schnell der Provider reagieren muss.

Kostenueberraschungen: Cloud-Kosten sind variabel. Ein falsch konfigurierter Cluster-Autoscaler kann in einer Nacht Tausende Euro an Compute-Kosten erzeugen. Setzen Sie Budgetalarme und Resource Quotas.

Compliance-Verantwortung bleibt bei Ihnen: Auch wenn der Provider die Infrastruktur betreibt -- die Verantwortung fuer DSGVO-konforme Datenverarbeitung liegt bei Ihrem Unternehmen. Ein Auftragsverarbeitungsvertrag (AVV) ist Pflicht, reicht aber allein nicht aus. Weitere Details zu Compliance-Themen finden Sie unter Kubernetes DSGVO Compliance.

Der hybride Weg: Was in der Praxis gut funktioniert

Die meisten erfolgreichen Setups, die wir sehen, sind hybrid:

1. Managed Control Plane (EKS/AKS/GKE) fuer die Basis-Infrastruktur
2. Terraform fuer reproduzierbare Cluster-Provisioning
3. Internes Team fuer Application-Operations, RBAC und Deployment-Pipelines
4. Externer Support fuer Architektur-Reviews, Security-Audits und Incident-Eskalation

Dieser Ansatz kombiniert die Kostenvorteile von Managed Services mit der Kontrolle ueber die eigene Anwendungslandschaft. Das interne Team muss kein Deep-Kubernetes-Wissen aufbauen, braucht aber solides Verstaendnis von Deployments, Services, RBAC und Monitoring.

Checkliste: Vor der Entscheidung

Bevor Sie sich festlegen, klaeren Sie diese Punkte:

• Wie viele Cluster betreiben Sie heute und in 12 Monaten?
• Wie viele Engineers arbeiten aktuell an Kubernetes-Operations?
• Gibt es ein On-Call-Rotation, die K8s-Infrastruktur abdeckt?
• Welche Compliance-Anforderungen gelten (DSGVO, ISO 27001, BSI-Grundschutz)?
• Ist Multi-Cloud oder Hybrid-Cloud ein Thema?
• Wie schnell muessen neue Cluster bereitstellbar sein?
• Was ist Ihr monatliches Budget fuer Kubernetes-Infrastruktur und -Betrieb?
• Gibt es bestehende Vertraege mit Cloud-Providern, die EDP-Rabatte beinhalten?

Fazit

Die Entscheidung "auslagern oder nicht" ist keine Glaubensfrage. Es ist eine Rechnung: Was kostet Eigenbetrieb wirklich (inklusive Personalkosten, Opportunitaetskosten und Risiko), und was kostet ein Managed Service im Vergleich?

Fuer die meisten mittelstaendischen Teams ist der Managed-Weg guenstiger und schneller -- nicht weil Managed Services billig waeren, sondern weil qualifiziertes Kubernetes-Personal teuer und schwer zu finden ist. Das gilt besonders auf dem aktuellen Arbeitsmarkt.

Wichtig ist, dass Sie die Entscheidung bewusst treffen und nicht aus Bequemlichkeit oder aus falschem Stolz. "Wir machen alles selbst" klingt souveraen, kostet aber oft mehr als notig und bindet Ressourcen, die an anderer Stelle fehlen.

Sie stehen vor der Entscheidung und brauchen eine neutrale Einschaetzung? Wir helfen bei der TCO-Analyse, Provider-Bewertung und Migrationsplanung. Melden Sie sich unter /kontakt.