Kubernetes für KI-Anwendungen: Skalierung richtig umsetzen

Ihre KI-Services sollen im Tagesgeschäft stabil antworten, während Trainingsjobs GPUs effizient auslasten – und das alles zu planbaren Kosten. Kubernetes ist dafür das stärkste Fundament, wenn Sie Skalierung sauber umsetzen.

In diesem Leitfaden zeigen wir, wie Sie KI-Workloads auf Kubernetes so designen, dass Durchsatz, Latenz und Budget im Gleichgewicht bleiben. Mit klaren Architektur-Bausteinen, erprobten Mustern und konkreten YAML-Beispielen.

Ergebnis: Weniger Firefighting, mehr reproduzierbare Performance – von der ersten GPU bis zum produktionsreifen KI-Cluster.

TL;DR

• Trennen Sie Workload-Pfade: Online-Inferenz (Deployment/Service) vs. Batch/Training (Jobs/Operatoren).
• Für GPUs: Device Plugin/Operator, dedizierte Nodepools, Taints/Tolerations, Affinity und ggf. MIG/Zeitslicing.
• Autoscaling: HPA (custom/external Metrics) für Inferenz, KEDA für Event-/Queue-Last, Cluster Autoscaler für Nodes.
• Datenpfade optimieren: Read-Only Modelvolumes, Cache/Warmup, objektbasiertes Storage für große Artefakte.
• Observability & Kosten: GPU-, Latenz- und Durchsatz-Metriken, SLOs definieren, Quotas/Budgets als Guardrails.

Was bedeutet Skalierung von KI-Workloads auf Kubernetes? (Definition)

Skalierung in Kubernetes für KI umfasst drei Dimensionen:

• Horizontal: Mehr/ weniger Pods und bei Bedarf mehr/ weniger Nodes (Cluster Autoscaler).
• Vertikal: Passende CPU/GPU/Memory pro Pod (VPA im Recommend-Modus, feste Requests/Limits).
• Orchestrierung: Richtige Zuweisung seltener Ressourcen (GPUs), Datenpfade mit ausreichendem Durchsatz und SLO-gerechte Latenzen.

Ziel ist nicht “maximale Auslastung um jeden Preis”, sondern ein belastbares Gleichgewicht aus Verfügbarkeit, Performance und Kosten.

Architektur-Bausteine für KI auf K8s

• Dedizierte GPU-Nodepools
  • Labels (z. B. accelerator=nvidia), Taints (gpu=true:NoSchedule), passende Instance-Typen.
• NVIDIA-Ökosystem
  • GPU Operator (Treiber/Toolkit), Device Plugin, DCGM Exporter für GPU-Metriken.
• Netzwerk & Ingress
  • Stabiler L7-Zugriff, optional Service Mesh (mTLS/Traffic-Shaping) für Inferenz.
• Storage & Datenpfade
  • StorageClasses für Modelle/Features (ReadOnlyMany für Modelle, Objekt-Storage für Artefakte).
• MLOps-Orchestrierung
  • Kubeflow, Ray, Argo Workflows, Operators (z. B. PyTorchJob, MPIJob) für verteiltes Training.
• Observability
  • Prometheus + Adapter für Custom/External Metrics (HPA), Logging/Tracing und Kostenexport.

Praxis-Tipp: Trennen Sie die Verantwortung: “Infrastruktur (Cluster/GPU)” vs. “ML-Plattform (Pipelines/Modelle)”. So bleiben Upgrades kalkulierbar und Teams entkoppelt.

Workload-Typen und passende Kubernetes-Objekte

Autoscaling richtig einsetzen: HPA, VPA, KEDA & Cluster Autoscaler

• Horizontal Pod Autoscaler (HPA v2)
  • Nutzen Sie Custom/External Metrics (z. B. P95-Latenz, QPS, GPU-Utilization). CPU allein ist für Inferenz oft irreführend.
  • Prometheus Adapter macht Metriken HPA-fähig.
• KEDA für Event-getriebene Skalierung
  • Skaliert Deployments/Jobs anhand von Queue-Länge (Kafka, RabbitMQ, SQS etc.) oder Streams.
• Vertical Pod Autoscaler (VPA)
  • Als “recommendation only” für Richtwerte, nicht parallel zu HPA auf denselben Ressourcen aktiv nutzen.
• Cluster Autoscaler
  • Sorgt für Node-Skalierung; kombinieren Sie mit dedizierten GPU-Nodegroups.
  • Guardrails: Max/Min Größen, Pod PriorityClasses, Budgetlimits.

Praxis-Tipp: Definieren Sie SLOs (z. B. “P95 < 150 ms bei 200 RPS”). Leiten Sie daraus HPA-Ziele ab und testen Sie Lastsprünge mit synthetischem Traffic.

GPU-Scheduling und Ressourcenmanagement

GPU-Kapazitäten sind knapp – Planbarkeit schlägt Bauchgefühl. Kernelemente:

• Device Plugin & Operator: Stellt nvidia.com/gpu bereit, automatisiert Treiber.
• Node Affinity: Pods nur auf GPU-Nodes planen.
• Taints/Tolerations: Abschirmen, damit nur GPU-Workloads diese Nodes nutzen.
• Sharing: MIG (Multi-Instance GPU) oder Zeitslicing, falls Workloads es erlauben.
• QoS: PriorityClasses und PodDisruptionBudgets für planbare Wartungsfenster.

Beispiel-Deployment für Inferenz mit 1 GPU und klaren Scheduling-Regeln:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-gpu
spec:
  replicas: 2
  selector:
    matchLabels:
      app: inference-gpu
  template:
    metadata:
      labels:
        app: inference-gpu
    spec:
      nodeSelector:
        accelerator: nvidia
      tolerations:
        - key: "gpu"
          operator: "Equal"
          value: "true"
          effect: "NoSchedule"
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: accelerator
                    operator: In
                    values: ["nvidia"]
      containers:
        - name: server
          image: yourrepo/inference:stable
          resources:
            requests:
              nvidia.com/gpu: "1"
              cpu: "1"
              memory: "4Gi"
            limits:
              nvidia.com/gpu: "1"
              cpu: "2"
              memory: "8Gi"
          ports:
            - containerPort: 8080

Daten, Storage und Durchsatz

• Modelle: Read-Only Volumes (ReadOnlyMany) oder On-Demand Download aus Objekt-Storage; Versionierung beibehalten.
• Caching/Warmup: Init-Container zum Vorladen heißer Modelle; Sidecar-Cache oder lokaler NVMe-Speicher für niedrige Latenz.
• Trainingsdaten: Große Datasets per Objekt-Storage streamen; Checkpoints regelmäßig wegspeichern.
• Durchsatzpfade: Für verteiltes Training auf Netzwerk-Latenz/Throughput achten; ggf. getrennte StorageClasses (fast/standard).

Praxis-Tipp: Messen Sie First-Byte-Latenz nach Pod-Start. Warmup senkt “kalte” Latenzspitzen drastisch und stabilisiert HPA-Verhalten.

Observability, Kosten und SLOs

• Metriken: GPU-Utilization, GPU-Memory, Inferenz-Latenzen (P50/P95), QPS, Queue-Längen; Export via DCGM/Prometheus.
• Logs/Tracing: Korrelation von Request-IDs zwischen Ingress, Service und Modell-Handler.
• Kosten-Transparenz: Labels/Annotations für Kostenstellen, GPU-Stunden pro Team/Service.
• SLO-Guardrails: Alerting auf Zielverletzungen, Autoscaling-Limits bewusst setzen, Preemption vermeiden.

Sicherheit und Governance

• Isolation: Separate Namespaces/Nodegroups für Teams; NetworkPolicies für minimalen Traffic.
• Images & SBOM: Reproduzierbare Builds, Scans in der CI.
• Secrets/Keys: Zugriff auf Modelle/Objekt-Storage über Secret Stores (z. B. CSI Secrets Store).
• Compliance: Audit-Logging, nachvollziehbare Pipelines, reproduzierbare Artefakte.

Schritt-für-Schritt: Von PoC zur produktionsreifen Skalierung

1. Anforderungen klären: SLOs (Latenz/Durchsatz), Kostenrahmen, Datenquellen, Security.
2. Nodepools planen: GPU-Typen, Labels/Taints, Min/Max-Kapazität, StorageClasses.
3. Baseline observierbar machen: DCGM, Prometheus Adapter, Request-Metriken, Tracing.
4. Workload-Schnitt: Inferenz (Deployment/Service) vs. Batch/Training (Jobs/Operatoren).
5. Autoscaling definieren: HPA-Ziele, KEDA-Trigger, Cluster Autoscaler-Grenzen.
6. Datenpfade bauen: Modelle versioniert, Warmup/Cache, Artefakte in Objekt-Storage.
7. Failover & Upgrades testen: PodDisruptionBudgets, Rolling Updates, Chaos/Load Tests.
8. Kosten-Guardrails: Quotas, PriorityClasses, Preemption-Policy, Reporting.

Produktions-Ready Checkliste für KI auf Kubernetes

• GPU-Nodes mit Labels/Taints, Device Plugin/Operator betriebsbereit
• Klare Requests/Limits inkl. nvidia.com/gpu je Pod
• HPA/KEDA-Ziele an SLOs gekoppelt, Prometheus Adapter aktiv
• Modelle als RO-Volume oder über Objekt-Storage versioniert eingebunden
• Warmup/Cache für kalte Starts implementiert
• DCGM-/App-Metriken, Logs und Tracing verknüpft
• PodDisruptionBudgets und PriorityClasses definiert
• Cluster Autoscaler mit Guardrails konfiguriert
• Sicherheitsregeln: NetworkPolicies, Secrets-Management, Image-Scanning
• Last-/Resilienztests regelmäßig automatisiert

Typische Fehler – und wie Sie sie vermeiden

• Nur auf CPU skalieren: Für Inferenz irrelevant. Nutzen Sie Latenz/QPS/GPU-Metriken.
• Keine Requests/Limits: Scheduler plant unzuverlässig; definieren Sie Ressourcen sauber.
• Gemischte Nodes ohne Taints: CPU-Workloads belegen GPU-Knoten – trennen und schützen.
• Kalte Modelle: Start-Latenz explodiert. Warmup/Cache frühzeitig einplanen.
• HPA und VPA gleichzeitig “aktiv”: VPA nur als Empfehlung, sonst Flattern.
• Datenpfade ignoriert: Training/Inferenz drosseln, wenn Storage/Netz nicht mitzieht.

Häufige Fragen (FAQ)

Brauche ich zwingend den NVIDIA GPU Operator?

Nicht zwingend, aber er vereinfacht Treiber-, Toolkit- und Monitoring-Setup erheblich. In produktiven Umgebungen reduziert er Drift und verkürzt die Mean Time to Recovery nach Node-Replacements.

Wie messe ich “richtige” Metriken für HPA bei Inferenz?

Nutzen Sie SLO-nahe Signale wie P95-Latenz oder Anfragen in Bearbeitung. GPU-Utilization kann ergänzen, ersetzt aber keine User-zentrierten Metriken. Der Prometheus Adapter macht diese Werte HPA-fähig.

Kann ich GPUs zwischen Pods teilen?

Ja, mit NVIDIA MIG oder Zeitslicing – sofern Ihr Workload das unterstützt. Achten Sie auf Scheduling- und Isolationsimplikationen und testen Sie die Latenzstabilität unter Last.

Was ist besser für Batch-Inferenz: Jobs oder Deployments?

Jobs. Sie sind für einmalige/finite Ausführungen gedacht und integrieren gut mit KEDA/Queues. Deployments eignen sich für dauerhafte Dienste mit klaren SLOs.

Wie gehe ich mit großen Modellen um?

Nutzen Sie Read-Only Volumes oder Objekt-Storage mit lokalem Cache. Laden und erwärmen Sie Modelle beim Start, um kalte Latenzen zu vermeiden, und versionieren Sie Artefakte konsequent.

Kann ich HPA und VPA zusammen verwenden?

Ja, aber vorsichtig: VPA im “recommendation”-Modus, HPA übernimmt die horizontale Skalierung. Vermeiden Sie konkurrierende Ziele auf denselben Ressourcen.

Wie plane ich gemischte Workloads (Training + Inferenz) im selben Cluster?

Trennen Sie per Namespace, Nodegroup, Taints/Tolerations und PriorityClasses. So bleibt die Inferenz SLO-stabil, während Trainingsjobs Auslastungsspitzen nutzen.

Welche Rolle spielt ein Service Mesh?

Für Inferenz kann ein Mesh mTLS, Retries, Timeouts und Canary-Releases standardisieren. Es ersetzt jedoch kein sauberes HPA-Design und keine optimierten Datenpfade.

Wie begrenze ich Kosten effektiv?

Setzen Sie ResourceQuotas/Budgets, definieren Sie Obergrenzen für Autoscaler und exportieren Sie GPU-Stunden pro Team. Reviews der SLOs vs. Kosten regelmäßig durchführen.

Fazit

Kubernetes liefert die Bausteine, um KI-Workloads kontrolliert und reproduzierbar zu skalieren – vorausgesetzt, GPU-Scheduling, Autoscaling und Datenpfade sind sauber designt. Wer Inferenz und Batch klar trennt, erhält stabile Latenzen und planbare Kosten.

Nutzen Sie die Checkliste und das YAML-Beispiel als Startpunkt für Ihr Cluster-Blueprint. Für fortgeschrittene Szenarien wie MIG/Zeitslicing, verteiltes Training und SLO-Feintuning folgen Sie unserem Blog für weitere Deep-Dives. Abonnieren Sie den technischen Newsletter und bleiben Sie bei Kubernetes & KI auf dem neuesten Stand.