Multi-Tenant Kubernetes für Managed Service Provider

TL;DR

• Multi-Tenancy auf Kubernetes laesst sich in drei Modellen umsetzen: Namespace-basiert, vCluster-basiert oder mit dedizierten Clustern -- jedes mit eigenem Kosten-Isolations-Tradeoff.
• vCluster bietet den besten Kompromiss fuer Managed Service Provider: starke Isolation bei geteilter Infrastruktur und Kosten unter 30% eines dedizierten Clusters.
• Noisy-Neighbor-Prevention erfordert ResourceQuotas, LimitRanges und Priority Classes -- ohne diese Mechanismen gefaehrdet ein Tenant die Stabilitaet aller anderen.
• Billing und Metering pro Tenant lassen sich ueber Labels, kubecost und die Kubernetes Metrics API automatisieren.
• SLA-Management pro Tenant braucht dedizierte Monitoring-Stacks und automatisierte Eskalationspfade.

Das Geschaeftsmodell: Kubernetes als Managed Service

Managed Service Provider (MSPs) und SaaS-Anbieter stehen vor derselben Frage: Wie betreiben wir Kubernetes-Workloads fuer viele Kunden auf gemeinsamer Infrastruktur, ohne bei Isolation, Performance oder Compliance Abstriche zu machen?

Ein dedizierter Cluster pro Kunde ist die einfachste Loesung -- und die teuerste. Bei 50 Kunden betreiben Sie 50 Control Planes, 50 Monitoring-Stacks und 50 Upgrade-Zyklen. Das skaliert weder technisch noch wirtschaftlich.

Multi-Tenancy loest dieses Problem, indem mehrere Tenants einen gemeinsamen Cluster oder eine gemeinsame Infrastruktur nutzen. Aber die Implementierung entscheidet ueber Erfolg oder Scheitern.

Die drei Isolationsmodelle im Vergleich

Modell 1: Namespace-basierte Isolation

Jeder Tenant bekommt einen oder mehrere Namespaces auf einem geteilten Cluster. RBAC, NetworkPolicies und ResourceQuotas trennen die Tenants.

# Tenant-Namespace mit allen Isolation-Primitiven
apiVersion: v1
kind: Namespace
metadata:
  name: tenant-acme
  labels:
    tenant: acme
    tier: standard
    billing-id: "ACME-2026-001"
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-quota
  namespace: tenant-acme
spec:
  hard:
    requests.cpu: "8"
    requests.memory: 16Gi
    limits.cpu: "16"
    limits.memory: 32Gi
    pods: "50"
    services: "10"
    persistentvolumeclaims: "20"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: tenant-limits
  namespace: tenant-acme
spec:
  limits:
    - default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      type: Container
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: tenant-isolation
  namespace: tenant-acme
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              tenant: acme
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              tenant: acme
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53

Vorteile: Geringste Kosten, einfachste Verwaltung, schnelle Provisionierung.

Nachteile: Geteilter API-Server, keine eigenen CRDs pro Tenant, Blast Radius bei Fehlkonfiguration auf Cluster-Ebene.

Modell 2: vCluster-basierte Isolation

Jeder Tenant erhaelt einen virtuellen Cluster mit eigenem API-Server, eigenem etcd und eigenem RBAC -- aber auf geteilter Node-Infrastruktur. Mehr Details zu vCluster unter vCluster Multi-Tenancy: Virtuelle Cluster.

apiVersion: infrastructure.cluster.x-k8s.io/v1alpha1
kind: VCluster
metadata:
  name: tenant-acme
  namespace: vcluster-acme
spec:
  controlPlaneEndpoint:
    host: tenant-acme.platform.example.com
    port: 443
  helmRelease:
    chart:
      repo: https://charts.loft.sh
      name: vcluster
      version: 0.20.0
    values: |
      syncer:
        extraArgs:
          ---tls-san=tenant-acme.platform.example.com
      sync:
        networkpolicies:
          enabled: true
        persistentvolumes:
          enabled: true
      isolation:
        enabled: true
        resourceQuota:
          enabled: true
          quota:
            requests.cpu: "16"
            requests.memory: 32Gi
            limits.cpu: "32"
            limits.memory: 64Gi

Vorteile: Eigener API-Server und etcd, eigene CRDs, eigene Kubernetes-Version, starke logische Isolation.

Nachteile: Hoeherer Ressourcenverbrauch als Namespaces (ca. 200-500 MB RAM pro vCluster), Node-Level-Isolation nicht automatisch.

Modell 3: Dedizierte Cluster

Jeder Tenant bekommt einen eigenen physischen oder managed Cluster. Maximale Isolation, maximale Kosten.

Empfehlung fuer MSPs: vCluster als Default, dedizierte Cluster nur fuer Enterprise-Tenants mit speziellen Compliance-Anforderungen.

Noisy-Neighbor-Prevention

Der groesste Feind einer Multi-Tenant-Plattform ist der Noisy Neighbor: ein Tenant, der ueberproportional viele Ressourcen verbraucht und andere Tenants beeintraechtigt.

CPU Throttling und Memory-Schutz

ResourceQuotas begrenzen die Gesamtressourcen pro Namespace. Aber innerhalb des Quotas kann ein einzelner Pod immer noch andere Pods verdraengen. LimitRanges setzen deshalb Grenzen auf Container-Ebene.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: tenant-standard
value: 100
globalDefault: false
description: "Standard-Prioritaet fuer Tenant-Workloads"
---
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: platform-critical
value: 1000
globalDefault: false
description: "Hohe Prioritaet fuer Plattform-Komponenten"

Platform-eigene Workloads (Monitoring, Ingress, DNS) erhalten eine hoehere Priority Class. Bei Ressourcenknappheit werden Tenant-Pods zuerst evicted, nicht Plattform-Komponenten.

Network Bandwidth Limiting

Kubernetes bietet nativ kein Network-Bandwidth-Limiting. Mit Cilium oder Calico lassen sich Bandbreiten-Limits pro Pod oder Namespace setzen:

# Cilium Bandwidth Manager - Limit pro Pod
kubectl annotate pod tenant-pod \
  kubernetes.io/egress-bandwidth=50M \
  kubernetes.io/ingress-bandwidth=50M

Billing und Metering pro Tenant

Ohne Kostentransparenz pro Tenant ist kein tragfaehiges Geschaeftsmodell moeglich. Das Billing-System besteht aus drei Komponenten:

1. Label-basierte Zuordnung

Jede Ressource traegt ein Tenant-Label. Crossplane oder der Onboarding-Controller setzen dieses Label automatisch.

2. Metering mit kubecost oder OpenCost

# kubecost API: Kosten pro Tenant der letzten 30 Tage
curl -s "http://kubecost:9090/model/allocation?window=30d&aggregate=label:tenant" \
  | jq '.data[] | to_entries[] | {tenant: .key, cost: .value.totalCost}'

Ergebnis:

{"tenant": "acme", "cost": 1247.50}
{"tenant": "globex", "cost": 892.30}
{"tenant": "initech", "cost": 2103.80}

3. Automatisierte Rechnungsstellung

Ein CronJob exportiert die Metering-Daten woechentlich oder monatlich in Ihr Billing-System (Stripe, SAP, eigene Loesung):

apiVersion: batch/v1
kind: CronJob
metadata:
  name: tenant-billing-export
  namespace: platform-system
spec:
  schedule: "0 2 1 * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: billing-export
              image: platform/billing-exporter:latest
              env:
                - name: KUBECOST_ENDPOINT
                  value: "http://kubecost.monitoring:9090"
                - name: BILLING_API_URL
                  value: "https://billing.internal/api/v1/usage"
          restartPolicy: OnFailure

Shared vs. Dedicated Control Plane

Fuer MSPs stellt sich die Frage: Einen grossen Cluster fuer alle Tenants oder mehrere regionale Cluster?

Shared Control Plane (ein Cluster):

• Einfacher zu betreiben und zu upgraden
• Kosteneffizient bei vielen kleinen Tenants
• Risiko: Single Point of Failure

Regional Dedicated Control Planes (mehrere Cluster):

• Bessere Latenz fuer regionale Tenants
• Blast Radius auf Region begrenzt
• Hoehere Betriebskomplexitaet

Die beste Strategie fuer die meisten MSPs: 2-3 regionale Cluster mit vCluster pro Tenant. Das bietet sowohl regionale Naehe als auch Kostenkontrolle. Mehr zu Multi-Tenancy-Strategien unter Multi-Tenancy in Deutschland.

Tenant-Onboarding-Automation

Ein neuer Tenant sollte in unter 10 Minuten vollstaendig provisioniert sein. Ein Onboarding-Controller automatisiert den gesamten Prozess:

apiVersion: platform.example.com/v1alpha1
kind: Tenant
metadata:
  name: acme
spec:
  displayName: "ACME Corporation"
  tier: professional
  admin:
    email: admin@acme.example.com
    group: tenant-acme-admins
  resources:
    cpuLimit: "32"
    memoryLimit: 64Gi
    storageLimit: 500Gi
  networking:
    ingressDomain: acme.platform.example.com
    dedicatedIngress: true
  sla:
    tier: gold
    uptimeTarget: "99.9%"
    supportHours: "24/7"

Der Controller erstellt automatisch:

• vCluster oder Namespace (je nach Tier)
• DNS-Eintraege und TLS-Zertifikate
• Monitoring-Dashboards in Grafana
• Alerting-Rules in Prometheus
• Kubeconfig und Zugangsdaten
• Eintrag im Billing-System

SLA-Management pro Tenant

Verschiedene Tenants haben verschiedene SLA-Anforderungen. Ein Gold-Tenant erwartet 99.9% Uptime und 15-Minuten-Reaktionszeit. Ein Bronze-Tenant akzeptiert 99% und Best-Effort-Support.

# Prometheus AlertRule fuer Gold-SLA Tenants
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: sla-gold-alerts
  namespace: monitoring
spec:
  groups:
    - name: sla-gold
      rules:
        - alert: TenantHighErrorRate
          expr: |
            sum(rate(http_requests_total{status=~"5..",tenant_sla="gold"}[5m]))
            / sum(rate(http_requests_total{tenant_sla="gold"}[5m])) > 0.01
          for: 2m
          labels:
            severity: critical
            escalation: pagerduty
          annotations:
            summary: "Gold-SLA Tenant {{ $labels.tenant }} hat Error-Rate ueber 1%"
        - alert: TenantPodNotReady
          expr: |
            kube_pod_status_ready{condition="false",namespace=~"tenant-.*"}
            * on(namespace) group_left(sla) kube_namespace_labels{label_sla="gold"} == 1
          for: 5m
          labels:
            severity: warning
            escalation: slack

Security-Isolation zwischen Tenants

Isolation ist nicht nur eine Frage von Namespaces und RBAC. Fuer Managed Service Provider gelten strengere Anforderungen. Detaillierte Security-Konzepte finden Sie unter Kubernetes Security Posture.

Pod Security Standards

apiVersion: v1
kind: Namespace
metadata:
  name: tenant-acme
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Das restricted Profil verhindert privilegierte Container, Host-Network-Zugriff und Root-Prozesse -- alles, was ein Tenant nicht braucht und was die Plattform gefaehrden koennte.

Secrets-Isolation

Tenant-Secrets muessen physisch getrennt gespeichert werden. Ein External Secrets Operator mit separaten Secret Stores pro Tenant stellt sicher, dass kein Tenant auf die Secrets eines anderen zugreifen kann:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: tenant-acme-vault
  namespace: tenant-acme
spec:
  provider:
    vault:
      server: "https://vault.internal:8200"
      path: "tenants/acme"
      auth:
        kubernetes:
          mountPath: "kubernetes"
          role: "tenant-acme"

Praxistipps fuer den Aufbau einer Multi-Tenant-Plattform

1. Starten Sie mit wenigen Tenants. Onboarden Sie 3-5 Pilottenants, bevor Sie skalieren. Die ersten Tenants decken 80% der Edge Cases auf.

2. Automatisieren Sie das Offboarding. Tenant kuendigt, Ressourcen muessen sauber entfernt werden. Ein manueller Prozess vergisst garantiert DNS-Eintraege oder PersistentVolumes.

3. Testen Sie Tenant-Isolation regelmaessig. Ein monatlicher Penetration-Test deckt Luecken auf bevor Kunden sie finden. Mehr dazu unter Platform Engineering auf Kubernetes.

Fazit

Multi-Tenant Kubernetes fuer Managed Service Provider ist technisch loesbar -- die Herausforderung liegt in der Operationalisierung. vCluster bietet den besten Kompromiss zwischen Isolation und Kosten. Automatisiertes Onboarding, Label-basiertes Billing und SLA-differenziertes Monitoring machen den Unterschied zwischen einer funktionierenden und einer profitablen Plattform.

Sie bauen eine Multi-Tenant Kubernetes-Plattform fuer Ihre Kunden auf? Wir unterstuetzen bei Architekturdesign, Isolationskonzepten und Billing-Integration -- von der Planung bis zum produktiven Betrieb. Jetzt Beratung anfragen.