Enterprise Kubernetes: Multi-Cluster-Architektur, GitOps und Platform Engineering

TL;DR

• Multi-Cluster ist ab ca. 50 Microservices oder mehreren Teams fast unvermeidbar -- die Frage ist nur, wie man es managed
• GitOps mit ArgoCD oder Flux macht Multi-Cluster-Deployments reproduzierbar und auditierbar
• Platform Engineering (Internal Developer Platform) reduziert die kognitive Last fuer Entwicklerteams erheblich
• Die groessten Kostentreiber sind nicht die Cluster selbst, sondern Netzwerk-Traffic zwischen Clustern und der Betriebsaufwand
• Managed Kubernetes (EKS, AKS, GKE) vs. Self-Managed ist keine Glaubensfrage, sondern eine Make-or-Buy-Entscheidung

Ab wann wird Kubernetes "Enterprise"?

Es gibt keine feste Grenze, aber typische Indikatoren zeigen, wann ein Setup ueber ein einzelnes Cluster hinauswaechst. Mehr als drei Teams deployen unabhaengig. Es gibt regulatorische Anforderungen an Umgebungstrennung. Workloads laufen in mehreren Regionen oder muessen getrennte Blast Radii haben.

An diesem Punkt reicht ein einzelner Cluster nicht mehr aus -- nicht technisch, sondern organisatorisch. Teams blockieren sich gegenseitig bei Cluster-Upgrades, RBAC-Regeln werden zu komplex, und ein Incident im Cluster betrifft alle.

Multi-Cluster-Architektur: Warum und Wie

Die haeufigsten Gruende fuer Multi-Cluster-Setups:

Ein pragmatisches Setup fuer die meisten Organisationen mit 5-15 Teams:

# Cluster-Topologie mit Terraform definieren
# terraform/clusters.tf

module "cluster_prod_eu" {
  source       = "./modules/eks-cluster"
  cluster_name = "prod-eu-central-1"
  region       = "eu-central-1"
  node_groups = {
    general = {
      instance_types = ["m6i.xlarge"]
      min_size       = 3
      max_size       = 20
      desired_size   = 5
    }
    compute = {
      instance_types = ["c6i.2xlarge"]
      min_size       = 0
      max_size       = 10
      desired_size   = 2
      taints = [{
        key    = "workload-type"
        value  = "compute"
        effect = "NO_SCHEDULE"
      }]
    }
  }
  kubernetes_version = "1.29"
  enable_encryption  = true
  kms_key_arn        = module.kms.key_arn
}

module "cluster_staging" {
  source       = "./modules/eks-cluster"
  cluster_name = "staging-eu-central-1"
  region       = "eu-central-1"
  node_groups = {
    general = {
      instance_types = ["m6i.large"]
      min_size       = 2
      max_size       = 8
      desired_size   = 3
    }
  }
  kubernetes_version = "1.29"
  enable_encryption  = true
  kms_key_arn        = module.kms.key_arn
}

Die Cluster-Definition in Terraform zu haben (statt manuell ueber Konsole) ist kein Nice-to-have, sondern Voraussetzung. Wenn der Staging-Cluster nicht reproduzierbar ist, testet man effektiv nichts.

GitOps als Deployment-Standard

Bei mehreren Clustern wird manuelles kubectl apply zum Risiko. GitOps loest das, indem Git die Single Source of Truth fuer den gewuenschten Cluster-Zustand wird. ArgoCD oder Flux gleichen kontinuierlich ab.

Ein typisches ArgoCD ApplicationSet, das eine App auf mehrere Cluster deployed:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: customer-api
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            env: production
        values:
          replicas: "3"
    - clusters:
        selector:
          matchLabels:
            env: staging
        values:
          replicas: "1"
  template:
    metadata:
      name: "customer-api-{{name}}"
    spec:
      project: default
      source:
        repoURL: https://git.company.de/platform/k8s-manifests.git
        targetRevision: main
        path: "apps/customer-api/overlays/{{metadata.labels.env}}"
      destination:
        server: "{{server}}"
        namespace: customer-api
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true
        retry:
          limit: 3
          backoff:
            duration: 5s
            maxDuration: 3m0s
            factor: 2

Der Vorteil: Jedes Deployment ist ein Git-Commit. Rollbacks sind git revert. Audit-Trails kommen gratis. Und neue Cluster bekommen automatisch alle Apps, wenn sie das richtige Label tragen.

Platform Engineering: Die Abstraktionsschicht

Enterprise Kubernetes bedeutet nicht, dass jeder Entwickler Kubernetes im Detail verstehen muss. Platform Engineering baut eine Abstraktionsschicht, die Entwickler nutzen koennen, ohne sich um Cluster-Details zu kuemmern.

Ein konkretes Beispiel: Statt 200 Zeilen YAML schreibt ein Entwicklerteam eine minimale App-Spec:

# Das ist, was ein Entwicklerteam schreibt:
apiVersion: platform.company.de/v1
kind: Application
metadata:
  name: payment-service
  namespace: payment
spec:
  image: registry.company.de/payment/api
  tag: v3.2.1
  replicas:
    min: 2
    max: 10
  resources:
    cpu: 500m
    memory: 512Mi
  ingress:
    host: payment-api.company.de
    tls: true
  database:
    type: postgresql
    size: small
  monitoring:
    alerts: true
    slo: 99.9

Ein Kubernetes Operator (z.B. mit Crossplane oder einem Custom Controller) generiert daraus automatisch: Deployment, Service, Ingress, HPA, PDB, NetworkPolicy, ServiceMonitor, PrometheusRules und die Datenbank-Instanz. Das reduziert Copy-Paste-Fehler und erzwingt Best Practices.

Kosten: Was Enterprise Kubernetes wirklich kostet

Die Cluster-Kosten selbst sind oft der kleinste Posten. Die echten Kostentreiber in der Uebersicht:

Die Personalkosten dominieren. Ein Platform Team von 3 Personen kostet mehr als die gesamte Infrastruktur. Deshalb ist die Frage "Managed vs. Self-Managed" primaer eine Personalfrage.

Ein sinnvolles Kostenoptimierungs-Script fuer die Praxis:

# Ueberblick: Node-Auslastung pro Cluster
# Hilft bei der Entscheidung, ob Nodes zu gross dimensioniert sind

for context in $(kubectl config get-contexts -o name); do
  echo "=== Cluster: $context ==="
  kubectl --context="$context" top nodes --no-headers | \
    awk '{
      cpu_pct = $3; mem_pct = $5;
      gsub(/%/, "", cpu_pct); gsub(/%/, "", mem_pct);
      total_cpu += cpu_pct; total_mem += mem_pct; count++
    }
    END {
      if (count > 0) {
        printf "  Nodes: %d\n", count
        printf "  Avg CPU: %.0f%%\n", total_cpu/count
        printf "  Avg Memory: %.0f%%\n", total_mem/count
        if (total_cpu/count < 30) print "  WARNUNG: CPU deutlich unter-ausgelastet"
        if (total_mem/count < 30) print "  WARNUNG: Memory deutlich unter-ausgelastet"
      }
    }'
done

Wenn die durchschnittliche Auslastung unter 30% liegt, sind die Nodes zu gross oder es laufen zu wenige Workloads. Karpenter (AWS) oder Cluster Autoscaler mit richtiger Konfiguration hilft hier.

Monitoring und Observability

Ein Enterprise-Setup ohne vernuenftiges Monitoring ist blind. Das Minimum:

• Metrics: Prometheus mit Thanos oder Mimir fuer Cross-Cluster-Aggregation
• Logs: Loki oder Elasticsearch fuer zentrales Log-Management
• Traces: OpenTelemetry mit Jaeger oder Tempo
• Alerting: Alertmanager mit PagerDuty/Opsgenie-Integration

Fuer Cross-Cluster-Monitoring mit Thanos braucht jeder Cluster einen Thanos Sidecar am Prometheus, der Metriken in einen zentralen Object Store schreibt. Eine zentrale Thanos Query-Instanz aggregiert dann ueber alle Cluster.

Haeufige Anti-Patterns

Anti-Pattern 1: Ein riesiger Cluster fuer alles. Klingt einfacher, wird aber zum Single Point of Failure. Cluster-Upgrades werden zum Hochrisiko-Event, weil alles gleichzeitig betroffen ist.

Anti-Pattern 2: Zu viele Cluster. Das andere Extrem. Jedes Team bekommt seinen eigenen Cluster. Ergebnis: 20 Cluster, die niemand konsistent verwalten kann. Der Sweet Spot liegt meist bei 3-7 Clustern.

Anti-Pattern 3: Kein Platform Team. Wenn jedes Produktteam seine eigene Kubernetes-Expertise aufbauen muss, wird Wissen fragmentiert. Ein dediziertes Platform Team, das die Basisinfrastruktur bereitstellt, ist ab 5 Entwicklerteams fast zwingend.

Anti-Pattern 4: YAML-Copy-Paste zwischen Environments. Staging und Production haben leicht unterschiedliche Configs. Kustomize Overlays oder Helm Values loesen das sauber.

Managed vs. Self-Managed: Entscheidungshilfe

Fuer die ueberwiegende Mehrheit der Unternehmen ist Managed Kubernetes die richtige Wahl. Self-Managed macht Sinn, wenn es harte On-Premises-Anforderungen gibt oder die Control Plane angepasst werden muss.

Verwandte Artikel

• ArgoCD GitOps Tutorial -- ArgoCD Schritt fuer Schritt einrichten
• Multi-Cluster Kubernetes -- Details zu Multi-Cluster-Strategien
• Kubernetes ROI berechnen -- ROI-Kalkulation fuer die Entscheidungsvorlage
• Kubernetes Platform Team aufbauen -- Rollen und Verantwortlichkeiten
• Cloud-Native Migration -- Von Legacy zu Kubernetes

Fazit

Enterprise Kubernetes ist kein Produkt, das man kauft, sondern eine Architektur-Entscheidung, die mit der Organisation wachsen muss. Multi-Cluster, GitOps und Platform Engineering sind die drei Bausteine, die ein skalierbares Setup ausmachen.

Der wichtigste Rat: Startet nicht zu gross. Ein Produktions-Cluster mit GitOps und einem kleinen Platform Team ist ein besserer Anfang als eine ambitionierte Multi-Cluster-Landschaft, die niemand betreiben kann.

Wenn Sie vor der Entscheidung stehen, ob und wie Kubernetes im Enterprise-Kontext fuer Ihre Organisation funktioniert, sprechen Sie uns an unter /kontakt. Wir helfen bei der Architektur-Bewertung und dem initialen Setup.