Kubernetes für SaaS: Wann es passt, wann ECS gewinnt, und was wir gewählt haben

Die Kubernetes-Entscheidung

Jedes Engineering-Team stellt sich irgendwann die Frage: Sollen wir Kubernetes einsetzen? Die ehrliche Antwort: Es kommt darauf an, was du betreibst, wie viele Services du hast und ob du dir den operativen Overhead leisten kannst.

Wir fahren drei unterschiedliche Compute-Strategien in Produktion. Eine Plattform läuft auf Kubernetes (7+ Services, Pimcore, OpenSearch, Worker). Eine andere läuft auf ECS Fargate + Lambda (Serverless-first, Event-driven). Eine dritte nutzt eine Mischung aus beidem. Jede war die richtige Wahl für ihren Kontext.

Dieser Artikel behandelt das Entscheidungsframework und die Implementierungsmuster für jeden Ansatz. Wie wir die Infrastructure as Code hinter diesen Deployments verwalten, findest du in unserem IaC-Leitfaden. Für die Anwendungsarchitekturen, die darauf laufen, schau dir unseren Systemarchitektur-Leitfaden an.

Der ehrliche Vergleich

Die echte Kostenaufschlüsselung

Für eine typische SaaS-Plattform mit 5 Services:

Kubernetes ist am günstigsten unter Last (effizientes Bin-Packing, Spot Instances, reservierte Kapazität). Lambda ist am günstigsten bei wenig Traffic (zahle nichts im Leerlauf). ECS Fargate ist der Mittelweg.

Wann du Kubernetes wählen solltest

Wähle Kubernetes, wenn du folgendes hast:

Komplexe Multi-Service-Systeme. Wenn du 7+ Services mit Abhängigkeiten, gemeinsamer Konfiguration, Service Discovery und koordinierten Deployments betreibst, orchestriert Kubernetes das gut. Einzelne Docker-Container auf ECS werden bei dieser Größenordnung schwer zu verwalten.

Stateful Workloads. Datenbanken, Suchmaschinen (OpenSearch, MeiliSearch), Message Broker (RabbitMQ) und Cache-Cluster (Redis) profitieren alle von Kubernetes StatefulSets, PersistentVolumeClaims und Operators. Das auf ECS zu betreiben erfordert externe Managed Services für jede einzelne Stateful-Komponente.

Multi-Cloud-Anforderungen. Kubernetes-Manifests funktionieren bei jedem Cloud-Provider. ECS und Lambda sind nur auf AWS verfügbar. Wenn du auf AWS und Azure laufen musst (oder in Zukunft musst), ist Kubernetes die portable Wahl.

Ein Platform-Team. Kubernetes erfordert laufende Wartung: Cluster-Upgrades (alle 3-4 Monate für Security-Patches), Node-Group-Management, Networking-Konfiguration (Ingress Controller, Network Policies) und RBAC-Management. Ohne eine dedizierte Person oder ein Team, das sich darum kümmert, wird der operative Overhead die gesamte Engineering-Organisation ausbremsen.

Kubernetes-Architektur für eine PIM/Commerce-Plattform

┌─────────────────────────────────────────────────────────────┐
│                    Kubernetes Cluster                         │
│                                                              │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐ │
│  │ Ingress      │  │ Cert-Manager│  │ External DNS        │ │
│  │ (Nginx/Traefik)│ │ (Let's Encrypt)│ │ (Route53 sync)  │ │
│  └──────┬───────┘  └─────────────┘  └─────────────────────┘ │
│         │                                                     │
│  ┌──────▼──────────────────────────────────────────────────┐ │
│  │                    Namespaces                            │ │
│  │                                                          │ │
│  │  ┌──────────────────────────────────────────────────┐   │ │
│  │  │  production namespace                             │   │ │
│  │  │                                                    │   │ │
│  │  │  pimcore-web (2-4 Replicas)                       │   │ │
│  │  │  pimcore-worker (1-3 Replicas)                    │   │ │
│  │  │  pimcore-ops (1 Replica, Wartung)                 │   │ │
│  │  │  frontend (2-3 Replicas)                          │   │ │
│  │  └──────────────────────────────────────────────────┘   │ │
│  │                                                          │ │
│  │  ┌──────────────────────────────────────────────────┐   │ │
│  │  │  data namespace                                   │   │ │
│  │  │                                                    │   │ │
│  │  │  mysql (StatefulSet, 1 Replica oder Managed)      │   │ │
│  │  │  redis (StatefulSet, 1 Replica oder Managed)      │   │ │
│  │  │  opensearch (StatefulSet, 2-3 Replicas)           │   │ │
│  │  │  rabbitmq (StatefulSet, 1-3 Replicas)             │   │ │
│  │  └──────────────────────────────────────────────────┘   │ │
│  │                                                          │ │
│  │  ┌──────────────────────────────────────────────────┐   │ │
│  │  │  flux-system namespace (GitOps Controller)        │   │ │
│  │  └──────────────────────────────────────────────────┘   │ │
│  └──────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

Deployment-Strategie: GitOps mit Flux

Wir nutzen Flux für GitOps-basierte Deployments. Das Git-Repository ist die einzige Quelle der Wahrheit. Flux gleicht den Cluster-Zustand jede Minute mit dem Repository ab.

# flux-system/kustomization.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
    name: platform
    namespace: flux-system
spec:
    interval: 1m
    sourceRef:
        kind: GitRepository
        name: infrastructure
    path: ./kubernetes/resources/overlay/prod
    prune: true  # Ressourcen entfernen, die aus Git gelöscht wurden
    healthChecks:
        - apiVersion: apps/v1
          kind: Deployment
          name: pimcore
          namespace: production

Vorteile gegenüber kubectl apply oder CI-gesteuerten Deployments:

• Drift-Erkennung und Korrektur. Wenn jemand eine Ressource manuell ändert, setzt Flux sie innerhalb von 1 Minute zurück.
• Git als Audit Trail. Jede Änderung ist ein Git-Commit mit Autor, Zeitstempel und Diff.
• Keine Cluster-Credentials im CI. Flux zieht aus Git. CI pusht nach Git. Die CI-Pipeline braucht niemals kubectl-Zugriff.
• Rollback ist git revert. Commit reverten, Flux gleicht ab, Rollback abgeschlossen.

Kustomize für Umgebungs-Overlays

kubernetes/resources/
├── base/
│   ├── deployments/
│   │   ├── pimcore.yaml
│   │   ├── frontend.yaml
│   │   └── worker.yaml
│   ├── services/
│   ├── configmaps/
│   └── kustomization.yaml
├── overlay/
│   ├── prod/
│   │   ├── patches/
│   │   │   ├── pimcore-replicas.yaml    # 4 Replicas
│   │   │   ├── resource-limits.yaml      # Höhere CPU/Memory
│   │   │   └── env-secrets.yaml          # Produktions-Secrets
│   │   └── kustomization.yaml
│   ├── staging/
│   │   ├── patches/
│   │   │   ├── pimcore-replicas.yaml    # 1 Replica
│   │   │   └── resource-limits.yaml      # Niedrigere Limits
│   │   └── kustomization.yaml
│   └── dev/
│       └── kustomization.yaml

Die Base-Manifests definieren die gemeinsame Struktur. Overlays patchen umgebungsspezifische Unterschiede (Replicas, Ressourcen-Limits, Secrets, Domains). Gleiche Anwendung, unterschiedliche Konfiguration pro Umgebung.

Wann ECS Fargate gewinnt

Wir haben für eine Commerce-Plattform ECS Fargate + Lambda statt Kubernetes gewählt. Die Gründe:

Einfachere Betriebsführung. Keine Cluster-Upgrades, kein Node-Management, keine RBAC-Konfiguration. ECS übernimmt Scheduling, Scaling und Health Checks. Das Team konzentriert sich auf Anwendungscode, nicht auf Infrastruktur.

Schnellere Skalierung. ECS Fargate startet neue Tasks in Sekunden. Kubernetes muss Pods schedulen, potentiell auf Node-Scaling warten (Minuten) und Health Checks bestehen lassen. Bei Traffic-Spitzen reagiert Fargate schneller.

Bessere Kosten bei variablen Workloads. Bezahlung pro laufendem Task, nicht pro Node. Wenn der Traffic nachts auf null fällt, sinken die Kosten proportional. Kubernetes-Nodes laufen weiter (und kosten weiter), unabhängig von der Last.

// ECS-Service-Definition (via CDK)
const service = new ecs.FargateService(this, 'ApiService', {
    cluster,
    taskDefinition,
    desiredCount: 2,
    assignPublicIp: false,
    vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS },
    circuitBreaker: { rollback: true },  // Automatisches Rollback bei Deployment-Fehler
    capacityProviderStrategies: [
        { capacityProvider: 'FARGATE_SPOT', weight: 2 },  // 66% Spot
        { capacityProvider: 'FARGATE', weight: 1 },        // 33% On-Demand
    ],
});

// Auto-Scaling
const scaling = service.autoScaleTaskCount({ minCapacity: 2, maxCapacity: 10 });
scaling.scaleOnCpuUtilization('CpuScaling', { targetUtilizationPercent: 70 });
scaling.scaleOnRequestCount('RequestScaling', {
    targetGroup,
    requestsPerTarget: 1000,
});

Lambda für Event-Driven Workloads

Lambda-Funktionen übernehmen Event-gesteuerte Workloads, die keinen dauerhaften Service rechtfertigen:

// Lambda für Webhook-Verarbeitung
const webhookHandler = new lambda.Function(this, 'WebhookHandler', {
    runtime: lambda.Runtime.NODEJS_20_X,
    handler: 'webhook.handler',
    timeout: cdk.Duration.seconds(30),
    memorySize: 256,
    environment: {
        TABLE_NAME: table.tableName,
        QUEUE_URL: queue.queueUrl,
    },
});

// API Gateway triggert Lambda
const api = new apigateway.RestApi(this, 'WebhookApi');
api.root.addResource('webhook').addMethod('POST',
    new apigateway.LambdaIntegration(webhookHandler)
);

Der Hybrid: ECS + Lambda

Die Architektur, die wir am häufigsten für Commerce-Plattformen nutzen:

Die Commerce API und Worker laufen auf Fargate (dauerhaft, langlebig). Alles Event-gesteuerte läuft auf Lambda (Pay-per-Use, Auto-Scaling). Die Kombination ist günstiger als alles auf Kubernetes und einfacher als alles auf Lambda.

Multi-Tenant-Isolation auf Kubernetes

Wenn du ein Multi-Tenant-SaaS auf Kubernetes betreibst, braucht die Tenant-Isolation explizite Konfiguration:

Namespace-Isolation

# Network Policy: Pods im tenant-a Namespace können nur untereinander kommunizieren
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
    name: tenant-isolation
    namespace: tenant-a
spec:
    podSelector: {}
    policyTypes:
        - Ingress
        - Egress
    ingress:
        - from:
            - namespaceSelector:
                matchLabels:
                    tenant: tenant-a
    egress:
        - to:
            - namespaceSelector:
                matchLabels:
                    tenant: tenant-a
        - to:  # DNS-Auflösung erlauben
            - namespaceSelector: {}
              podSelector:
                matchLabels:
                    k8s-app: kube-dns
            ports:
                - port: 53
                  protocol: UDP

Resource Quotas

Verhindere, dass ein Tenant alle Cluster-Ressourcen verbraucht:

apiVersion: v1
kind: ResourceQuota
metadata:
    name: tenant-a-quota
    namespace: tenant-a
spec:
    hard:
        requests.cpu: "4"          # Max 4 CPU-Kerne
        requests.memory: "8Gi"     # Max 8GB RAM
        limits.cpu: "8"
        limits.memory: "16Gi"
        pods: "20"                 # Max 20 Pods
        services: "10"
        persistentvolumeclaims: "5"

Das Noisy-Neighbor-Problem

Selbst mit Resource Quotas kann ein I/O-intensiver Workload eines Tenants andere auf dem gleichen Node beeinträchtigen. Lösungen:

Für die meisten SaaS-Anwendungen reichen Shared Nodes mit Resource Quotas aus. Reserviere dedizierte Node Pools für Enterprise-Tenants mit strikten Isolationsanforderungen. Für die Anwendungsebenen-Isolationsmuster (API-Middleware, Query-Filter, Policies) schau dir unseren Multi-Tenant-Design-Leitfaden an.

Kostenoptimierung

Spot Instances (Kubernetes)

Spot Instances sind 60-90% günstiger als On-Demand. Nutze sie für Stateless Workloads, die Unterbrechungen verkraften können:

# EKS Managed Node Group mit Spot Instances
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
    name: production
    region: eu-central-1
managedNodeGroups:
    - name: spot-workers
      instanceTypes: ["t3.large", "t3.xlarge", "m5.large"]
      spot: true
      minSize: 2
      maxSize: 10
      desiredCapacity: 3
      labels:
          node-type: spot
    - name: on-demand-workers
      instanceTypes: ["t3.large"]
      minSize: 1
      maxSize: 3
      desiredCapacity: 1
      labels:
          node-type: on-demand

Stateless Services (Webserver, Worker) laufen auf Spot. Stateful Services (Datenbanken, Suchmaschinen) laufen auf On-Demand. Nutze Pod Anti-Affinity, um Replicas über Nodes zu verteilen, damit eine Spot-Unterbrechung nicht alle Replicas herunterzieht.

Richtige Dimensionierung

Die meisten Teams überprovisionieren. Ein Service, der 1 CPU und 2GB RAM anfordert, nutzt tatsächlich vielleicht 0,2 CPU und 400MB. Überprovisionierung verschwendet Geld. Unterprovisionierung verursacht OOM Kills.

# Tatsächliche Ressourcennutzung vs. Anforderungen prüfen
kubectl top pods -n production
# Mit Ressourcenanforderungen in den Deployment-Manifests vergleichen
kubectl get pods -n production -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].resources.requests}{"\n"}{end}'

Nutze den Vertical Pod Autoscaler (VPA) im Empfehlungsmodus, um zu sehen, was deine Pods wirklich brauchen:

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
    name: pimcore-vpa
spec:
    targetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: pimcore
    updatePolicy:
        updateMode: "Off"  # Nur Empfehlung, nicht automatisch anwenden

Autoscaling

Der Horizontal Pod Autoscaler (HPA) skaliert basierend auf Metriken:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
    name: pimcore-hpa
spec:
    scaleTargetRef:
        apiVersion: apps/v1
        kind: Deployment
        name: pimcore
    minReplicas: 2
    maxReplicas: 8
    metrics:
        - type: Resource
          resource:
              name: cpu
              target:
                  type: Utilization
                  averageUtilization: 70
        - type: Resource
          resource:
              name: memory
              target:
                  type: Utilization
                  averageUtilization: 80
    behavior:
        scaleDown:
            stabilizationWindowSeconds: 300  # 5 Min. warten vor dem Herunterskalieren
            policies:
                - type: Pods
                  value: 1
                  periodSeconds: 60  # Max 1 Pod pro Minute entfernen

Die stabilizationWindowSeconds verhindern Flapping (hoch, runter, hoch). Die scaleDown.policies verhindern aggressives Herunterskalieren, das bei der nächsten Traffic-Spitze Kapazitätsprobleme verursachen könnte.

Das Networking-Minenfeld

Kubernetes Networking ist der Punkt, an dem die meisten Teams hängenbleiben.

Ingress Controller

Für die meisten SaaS-Plattformen reicht Nginx Ingress + cert-manager (Let's Encrypt) aus. Füge ein Service Mesh (Istio, Linkerd) nur hinzu, wenn du mTLS zwischen Services, erweitertes Traffic Routing (Canary Deployments, Traffic Splitting) oder detaillierte Service-to-Service-Observability brauchst.

DNS-Auflösungsprobleme

Ein häufiges Produktionsproblem: Pods können externe Hostnamen nicht auflösen, weil die DNS-Konfiguration falsch ist.

# Die korrekte DNS-Service-IP im Cluster finden
kubectl get svc -n kube-system kube-dns -o jsonpath='{.spec.clusterIP}'

# Wenn nginx-Configs einen Resolver referenzieren, diese IP verwenden
# Häufiger Fehler: 10.0.0.10 verwenden, obwohl der echte DNS bei 10.2.0.10 liegt

Wenn dein nginx-Sidecar Requests an externe Services weiterleitet (Cloud-Speicher, externe APIs), muss die resolver-Direktive auf die kube-dns-IP des Clusters zeigen, nicht auf einen hartcodierten Wert.

Häufige Fallstricke

1. Kubernetes wählen, weil "alle es benutzen." Wenn du 3 Services und ein kleines Team hast, ist ECS Fargate einfacher und günstiger. Kubernetes macht Sinn ab 7+ Services mit einem Platform-Team.

2. Kein GitOps. kubectl apply vom Entwickler-Laptop ist keine Deployment-Strategie. Nutze Flux oder ArgoCD für Reconciliation-basierte Deployments.

3. Shared Cluster ohne Resource Quotas. Ein Tenant oder ein außer Kontrolle geratener Pod verbraucht alle Ressourcen. Jeder Namespace braucht Resource Quotas.

4. Alle Pods auf On-Demand-Instances. Spot Instances sind 60-90% günstiger für Stateless Workloads. Nutze sie für Webserver und Worker.

5. Ressourcen überprovisionieren. Pods, die 2 CPU anfordern und 0,2 CPU nutzen, verschwenden Geld. Nutze VPA-Empfehlungen zur richtigen Dimensionierung.

6. Aggressives Autoscaling. Zu schnelles Herunterskalieren verursacht Kapazitätsprobleme bei der nächsten Spitze. Nutze Stabilisierungsfenster und schrittweise Scale-Down-Policies.

7. Keine Network Policies. Ohne sie kann jeder Pod mit jedem anderen Pod im Cluster kommunizieren. In einem Multi-Tenant-Setup ist das ein Sicherheitsproblem.

8. Cluster-Upgrades ignorieren. Kubernetes-Versionen erreichen alle 12-15 Monate ihr End-of-Life. Plane vierteljährliche Upgrade-Fenster. Zurückzufallen erzeugt Sicherheitslücken und blockiert neue Features.

9. Stateful und Stateless auf den gleichen Nodes mischen. Ein OpenSearch-Pod und ein Webserver-Pod, die um I/O auf dem gleichen Node konkurrieren, verschlechtern beide. Nutze Node Affinity, um sie zu trennen.

10. Keine Sealed Secrets. Plain Secrets in Git zu committen ist ein Sicherheitsvorfall, der nur darauf wartet zu passieren. Nutze Sealed Secrets, External Secrets Operator oder AWS Secrets Manager.

Wichtigste Erkenntnisse

• Kubernetes für komplexe Multi-Service-Plattformen. 7+ Services, Stateful Workloads, Multi-Cloud-Anforderungen und ein Team, das den operativen Overhead bewältigen kann.

• ECS Fargate für einfachere Container-Workloads. Gleiche Container, weniger operative Komplexität. Besser für Teams ohne Kubernetes-Expertise.

• Lambda für Event-gesteuerte Workloads. Webhooks, geplante Tasks, Bildverarbeitung und jeder Workload, der stoßweise und kurzlebig ist. Null Kosten im Leerlauf.

• Der Hybrid (ECS + Lambda) ist oft die beste Antwort. Dauerhafte Services auf Fargate, Event-gesteuertes auf Lambda. Günstiger als Kubernetes für alles, einfacher als Lambda für alles.

• GitOps mit Flux bietet echte Reconciliation. Nicht nur Deployment-Automatisierung. Drift-Erkennung, Audit Trail und Rollback via git revert.

• Spot Instances sparen 60-90% bei Stateless Workloads. Webserver und Worker auf Spot laufen lassen. Datenbanken und Suchmaschinen auf On-Demand.

• Multi-Tenant-Isolation braucht Network Policies und Resource Quotas. Namespace-Isolation allein reicht nicht. Erzwinge Netzwerkgrenzen und Ressourcen-Limits pro Tenant.

Wir deployen und verwalten Kubernetes-, ECS- und Lambda-Infrastruktur als Teil unserer Cloud-Services. Wenn du Hilfe bei der Wahl einer Compute-Strategie oder der Optimierung deines bestehenden Deployments brauchst, sprich mit unserem Team oder fordere ein Angebot an. Schau dir auch unseren Pimcore-Upgrade-Leitfaden für Kubernetes-spezifische Deployment-Muster mit Pimcore an.