AI auf Kubernetes starten: Plattform statt Roh-Cluster

TL;DR

• Kubernetes ist für AI geeignet, weil es flexibel ist: Custom Scheduling, verteilte Ressourcen, Self-Healing, riesiges Ökosystem.
• Kubernetes allein reicht nicht. Ohne Plattform-Schicht treffen Data Scientists auf Gang-Scheduling, Image-Größen, GPU-Quotas und Serving-Lücken.
• Training, Inference und Serving sind unterschiedliche Betriebsprobleme — ein Deployment-Manifest löst sie nicht alle.
• Projekte wie Flyte bridgen Ops und Model-Entwicklung über eine gemeinsame API: Entwickler fordern Acceleratoren an, die Plattform liefert sie.
• Einstieg: erst Pipeline und Metriken klären, dann GPU-Pool, dann Serving — nicht umgekehrt.

Was „AI auf Kubernetes" wirklich meint

AI ist keine einzelne Workload-Art. Es ist eine Kombination aus Disziplinen: Daten vorbereiten, Modelle trainieren, evaluieren, ausliefern, überwachen. Maschinen „denken" nicht — sie approximieren Aufgaben, die früher menschliche Kognition brauchten.

Auf dem Cluster landet das als:

Alles teilt sich „arme" Nodes — und bei LLMs werden die Nodes teuer und groß.

Warum Kubernetes trotzdem die richtige Basis ist

In der Praxis bleibt Kubernetes die Wahl, weil:

1. Flexibilität — eigene Scheduling-Logik und Device-Modelle sind möglich
2. Ökosystem — Device Plugins, Workflow-Engines, Observability
3. Self-Healing — Jobs und Serving überleben Node-Ausfälle besser als Ad-hoc-VMs
4. Portabilität — On-Prem, Cloud, Hybrid mit ähnlichem Betriebsmodell

Die Community arbeitet daran, Kubernetes für AI „besser" zu machen (Accelerator-Awareness, DRA, Queues). Bis dahin gilt: Ihr baut eine Plattform auf Kubernetes — Kubernetes ist nicht die Plattform.

Die Betriebsfallen, die Tutorials auslassen

Gang-Scheduling / Co-Scheduling

Distributed Training braucht oft, dass alle Worker gleichzeitig starten. Der Default-Scheduler tut das nicht zuverlässig. Open-Source-Optionen (u. a. Volcano, Apache YuniKorn, Co-Scheduling-Plugins) lösen das unterschiedlich — es gibt kein einziges „richtiges" Gang-Scheduling.

Cluster-Autoscaler und HPA sind Table Stakes für klassische Apps; mit Gang-Scheduling sind sie oft nicht out-of-the-box kompatibel. Das früh zu testen spart Wochen.

Image- und Modellgröße

Trainings-Images und Modell-Artefakte sprengen übliche Pull-Zeiten. Lazy-Load, Caches und klare Artifact-Pipelines gehören zur Plattform — nicht zum Notebook des Data Scientists.

Inference ≠ Training

Ein trainiertes Modell braucht einen Serving-Pfad: Endpoint, Skalierung, Observability. Manche Teams vermeiden Autoscaling bewusst („ein großes Pod pro Node"), um Cold-Starts und Rehydrate zu umgehen. Beides sind valide Muster — aber bewusste Entscheidungen.

# Minimal: GPU-Training-Job (ohne Gang-Scheduler — nur Skizze)
apiVersion: batch/v1
kind: Job
metadata:
  name: train-job
spec:
  template:
    spec:
      restartPolicy: OnFailure
      containers:
        - name: trainer
          image: your-registry/train:1.2.0
          resources:
            limits:
              nvidia.com/gpu: 1
          args: ['python', 'train.py', '--config', '/config/job.yaml']

Die Plattform-Schicht: APIs zwischen Ops und ML

Model-Entwickler wollen Genauigkeit — jetzt. Ops will Quotas, Kosten und Stabilität. Die Brücke ist eine konsistente API, die Infrastruktur-Details abstrahiert.

Flyte (CNCF, schnelle Graduation, Produktion u. a. bei großen Tech-Firmen) ist ein Beispiel: Workflows als Code, Acceleratoren als Deklaration.

# Konzept: Accelerator-Bedarf aus Entwickler-Sicht (Flyte-Stil)
@task(
    requests=Resources(cpu="2", mem="8Gi", gpu="1"),
    # Plattform mappt das auf Nodes mit z. B. NVIDIA T4
)
def embed_documents(docs: list[str]) -> list[list[float]]:
    ...

Der Entwickler spezifiziert „ich brauche einen Accelerator". Ops stellt sicher, dass der Pool existiert, getainted und überwacht ist. Genau diese Trennung fehlt, wenn Teams „roh" YAML in den Cluster pushen.

Ähnliche Ideen verfolgen Kubeflow, Argo Workflows + eigene Glue — und auf App-Ebene Llama Stack für GenAI-APIs.

Pragmatischer Einstiegspfad

# 1) GPU-Node-Pool absichern (Taint)
# 2) Device Plugin / GPU Operator
# 3) Ein Serving-Endpoint mit Metriken
# 4) Erst dann Multi-Node-Training + Queue
apiVersion: v1
kind: Namespace
metadata:
  name: ml-platform
  labels:
    purpose: ai-workloads

1. Use-Case scharf stellen: Batch-Inference, Chat-RAG oder Training?
2. Einen GPU-Pool mit Taints, Quotas und DCGM-Metriken
3. Ein Serving-Minimalprodukt (ein Modell, ein Endpoint, ein Dashboard)
4. Workflow-API einführen (Flyte/Argo/…), bevor fünf Teams fünf YAML-Stile erfinden
5. Gang-Scheduling und Autoscaler erst testen, wenn Training wirklich multi-node wird
6. GenAI-Extras (DRA, LLM-D, Agent-Sandbox) aus der AI-at-Scale-Serie nachziehen

Wer nur aus Neugier experimentiert, sieht die Fallen später. Wer Produktion plant, baut die Plattform bewusst — sonst wird Kubernetes zum teuren Notebook-Host.

Fazit

AI auf Kubernetes starten heißt nicht „GPU-Node an, fertig". Es heißt: Phasen (Training, Inference, Serving) trennen, Scheduling-Lücken kennen und eine API zwischen ML und Ops legen.

Kubernetes bleibt die richtige Basis wegen Flexibilität und Ökosystem. Der Hebel ist die Plattform darauf — sonst scheitert der Einstieg an Gang-Scheduling, Images und fehlendem Serving, nicht am Container-Runtime.

FAQ

Reicht Kubeflow allein? Es kann Teil der Antwort sein — ersetzt aber weder GPU-Betrieb noch klare Produktentscheidungen (welche Modelle, welche SLOs).

Wann brauche ich Gang-Scheduling? Sobald Distributed Training alle Worker gleichzeitig braucht. Einzel-GPU-Jobs oft nicht.

Flyte oder Argo? Beide können Workflows. Flyte zielt stärker auf ML-APIs und Accelerator-Abstraktion; Argo ist im GitOps-/CI-Umfeld oft schon da. Entscheidung nach Team-Fit, nicht nach Hype.

Verwandte Artikel

• Kubernetes AI & Machine Learning
• GPU Workloads auf Kubernetes
• GPU in Kubernetes: CDI, Sharing und DRA
• Kubernetes AI at Scale
• Ray auf Kubernetes
• Agentic AI auf Kubernetes in der Praxis