Projekt anfragen
Rückseite einer Leiterplatte mit goldfarbenen Leiterbahnen vor schwarzem Hintergrund

Managed Services · GPU-Kubernetes und KI-Plattform

Managed GPU & KI-Plattformen: Betrieb mit klarer Verantwortung

Ihr GPU-Cluster läuft produktiv, und jemand muss Treiber, Operator, Kapazität und Störungen im Griff haben. SKAFFON übernimmt diesen Betrieb mit schriftlich geregelter Verantwortung, rund um die Uhr (24/7).

Projekt anfragen Zur Verantwortungsmatrix
  • Kubernetes, GPU Operator und Treiber im Takt
  • GPU-Kapazität von Cloud-Anbietern wie STACKIT oder IONOS
  • Betrieb und Support 24/7

Autor: Ibrahim Yesilay, Gründer und Geschäftsführer Stand:

01Ausgangslage

Nach der Abnahme beginnt die eigentliche Arbeit am GPU-Cluster

SKAFFON betreibt GPU-Kubernetes-Cluster und die KI-Plattform darum: Updates von Kubernetes, GPU Operator und Treibern, Kapazitätsmanagement, Monitoring der GPU-Zustände, Störungsbearbeitung und Wiederherstellung.

Die Seite richtet sich an IT-Leitung und Plattformverantwortliche, die GPU-Cluster produktiv betreiben und die Betriebsverantwortung mit klar geregelten Zuständigkeiten an einen Dienstleister geben wollen.

SKAFFON betreibt dafür keine eigenen GPUs: Die GPU-Kapazität stammt von Cloud-Anbietern wie STACKIT oder IONOS oder aus Ihrer eigenen Hardware; SKAFFON betreibt die Plattform darauf. Wer Kapazität beschafft, regelt die Verantwortungsmatrix. Reaktionszeiten richten sich nach dem Servicelevel-Rahmen, Kennzahlen legt der Vertrag fest.

02Abgrenzung

Aufbau und Betrieb sind zwei getrennte Aufträge

Der Aufbau eines GPU-Clusters (Sizing, Netzwerk, Provisionierung, Abnahme) ist ein Projekt. Der Betrieb beginnt nach der Abnahme und ist ein Dauerauftrag mit eigenem Vertrag: Wer reagiert, wer entscheidet über Updates, wer plant Kapazität, was passiert bei einem GPU-Ausfall?

Wer beides beauftragt, bekommt eine nahtlose Übergabe; wer nur den Betrieb sucht, startet mit einer Bestandsaufnahme.

Nahaufnahme einer Hauptplatine mit Spule und Kondensatoren, geringe Schärfentiefe

03Betriebsumfang

Sieben Aufgaben, die wir am GPU-Cluster laufend erledigen

  • Cluster-Lifecycle

    Node-Pools, Skalierung, Austausch von Knoten, Konfiguration als Code.

  • Updates und Patching

    Kubernetes, Node-Betriebssystem, NVIDIA GPU Operator mit Treibern, Container-Runtime und Add-ons, nach dem unten beschriebenen Verfahren.

  • GPU-Kapazität

    Auslastung je GPU-Pool, Warteschlangen, Quoten je Team, Empfehlung für Erweiterung oder Umverteilung.

  • GPU-Monitoring

    DCGM-Exporter liefert GPU-Telemetrie im Prometheus-Format (NVIDIA/dcgm-exporter); Prometheus und Grafana stellen sie dar. Alarmierung nach dem Klassenmodell unter Managed Monitoring.

  • GitOps

    Auslieferung über Argo CD; Änderungen als Pull Request.

  • Recovery

    Velero für Cluster-Ressourcen und Volumes; Modellartefakte und Daten nach dem Backup-Konzept des jeweiligen Speichers.

  • Betriebsbericht

    Regelmäßig zu Incidents, Changes, Versionsstand, GPU-Auslastung und Kapazität.

04RACI

Wer am GPU-Cluster wofür geradesteht

R = führt aus, A = trägt die Ergebnisverantwortung, C = wird konsultiert, I = wird informiert. Standardaufteilung; der Vertrag legt die endgültige Fassung fest.

Verantwortungsmatrix für den Betrieb eines GPU-Kubernetes-Clusters, SKAFFON und Kunde
TätigkeitSKAFFONKunde
Cluster-Konfiguration als Code pflegenR/AC
Kubernetes-Upgrade und Node-UpdatesRA (Freigabe Fenster)
GPU Operator und Treiber aktualisierenRA (Freigabe Fenster)
GPU-Monitoring und Alarmierung betreibenR/AI
Störung auf Plattformebene (Nodes, Operator, Netzwerk, Storage)R/AI
Defekte GPU oder Server (Hardware)CR/A (bei eigener Hardware)
Störung im Workload (Modell, Serving-Software, Anwendung)CR/A
Quoten, Priorisierung zwischen Teams (fachliche Entscheidung)CR/A
Kapazitätsbericht und EmpfehlungRA
Beschaffung und BudgetCR/A
Backup einrichten, Restore-TestsR/AC
Daten und Modellartefakte: Verantwortung für InhaltCR/A
Zugriffskonzept und Mandantentrennung umsetzenRA
Betriebsreview und EskalationRA

05Update-Runbook

Treiber, CUDA, Runtime und Kubernetes müssen zusammenpassen

GPU-Komponenten bedingen sich. Deshalb folgt jedes Update einer festen Reihenfolge in acht Schritten.

Upgrade-Reihenfolge im GPU-ClusterAcht Schritte von der Vorbereitung bis zur DokumentationUpgrade-Reihenfolge im GPU-ClusterTreiber, CUDA, Container-Runtime und Kubernetes-Version müssen zueinander passen 1 Vorbereitung Kompatibilität prüfen 2 Kapazitätscheck Jobs & Fenster 3 Absicherung Backup und Restore-Weg 4 Test-Pool gleiche GPU-Klasse 5 Operator-Update CRDs, Treiber-DaemonSet 6 Kubernetes-Update Control Plane, Node-Pools 7 Verifikation GPU-Erkennung, DCGM 8 Dokumentation Betriebsbericht, Runbooks Schritt 7 und 8 schließen jedes Update ab; vor jedem Node-Wechsel wird der Treiber-Zustand geprüft.
Upgrade-Reihenfolge im GPU-ClusterAcht Schritte von der Vorbereitung bis zur Dokumentation Upgrade-Reihenfolgeim GPU-Cluster Treiber, CUDA, Container-Runtime undKubernetes-Version müssen zueinanderpassen 1 Vorbereitung Kompatibilität prüfen 2 Kapazitätscheck Jobs & Fenster 3 Absicherung Backup und Restore-Weg 4 Test-Pool gleiche GPU-Klasse 5 Operator-Update CRDs, Treiber-DaemonSet 6 Kubernetes-Update Control Plane, Node-Pools 7 Verifikation GPU-Erkennung, DCGM 8 Dokumentation Betriebsbericht, Runbooks Schritt 7 und 8 schließen jedes Update ab;vor jedem Node-Wechsel wird derTreiber-Zustand geprüft.

06Schritt für Schritt

Die acht Schritte eines GPU-Cluster-Updates im Detail

  1. 01

    Vorbereitung

    Kompatibilität

    Release Notes und Kompatibilität von Kubernetes, GPU Operator und Treiber prüfen. Der Operator-Chart und die Operator-Version sind im Code fixiert; ein Update ist eine bewusste Änderung.

  2. 02

    Kapazitätscheck

    Laufende Last

    Laufende Jobs und Inferenz-Dienste erfassen. Während Nodes nacheinander ausgetauscht werden, steht weniger GPU-Kapazität zur Verfügung; Fenster und Reihenfolge richten sich nach dem Bedarf.

  3. 03

    Absicherung

    Rückfall

    Frisches Backup, geprüfter Restore-Weg, Rückfallkriterien. Rückfall bedeutet Rückkehr auf einen gesicherten Zustand, nicht ein Downgrade der Control Plane.

  4. 04

    Test

    Test-Pool

    Update zuerst in einem Test-Pool oder -Cluster mit derselben GPU-Klasse, soweit vorhanden.

  5. 05

    Operator-Update

    CRDs und Treiber-DaemonSet

    Laut NVIDIA-Dokumentation aktualisiert Helm vorhandene CRDs nicht von selbst; sie werden manuell eingespielt oder über den Helm-Hook (seit v24.9.0 standardmäßig aktiv). Das Treiber-DaemonSet hat besondere Anforderungen und wird getrennt geplant.

  6. 06

    Kubernetes- und Node-Update

    Rollierend

    Control Plane zuerst, dann Node-Pools rollierend: Cordon, Drain unter Beachtung von PodDisruptionBudgets, Austausch, Treiber-Zustand prüfen, bevor der nächste Node folgt.

  7. 07

    Verifikation

    Abnahme durch Sie

    GPU-Erkennung, Zustand im DCGM-Monitoring, Testläufe mit einem Test-Workload, Prüfung der Alarme und Dashboards, Abnahme durch Sie.

  8. 08

    Dokumentation

    Ergebnis

    Festhalten im Betriebsbericht und in den Runbooks.

STACKIT-Besonderheit

Nach jedem Betriebssystem-Update die Treiberinstallation prüfen

Auf STACKIT besteht nach einem Betriebssystem-Update ein kleines Risiko, dass die Treiberinstallation scheitert (STACKIT, NVIDIA-GPUs in SKE). Deshalb gehört die Treiberprüfung in jeden Update-Schritt.

07Kapazität

Fünf Prüfpunkte, ob Ihre GPUs richtig dimensioniert sind

  • Auslastung je GPU-Pool über einen längeren Zeitraum, nicht nur Spitzen.
  • Wartezeiten und Abbrüche durch fehlende GPUs, getrennt nach Team.
  • Speicherbedarf der Modelle gegen GPU-Speicher; Hinweise zur Rechnung im Rechenbeispiel zu Modellgrößen.
  • Quoten und Prioritäten sind dokumentiert und ändern sich nur über Pull Request.
  • Kostenreport je Team oder Projekt, damit Kapazitätsentscheidungen nachvollziehbar bleiben.

08Betriebsprozesse

Störung, Änderung, Sicherheitsupdate: drei Abläufe im GPU-Betrieb

  • Störung

    Erkennung, Priorisierung, Eingrenzung (GPU, Operator, Netzwerk, Workload), Behebung oder Workaround, Statusinformation, Abschluss mit Ihrer Bestätigung, bei schweren Störungen Ursachenanalyse mit Maßnahmen.

  • Änderung

    Pull Request im GitOps-Repository, Review, Einstufung, Freigabe durch Sie, Umsetzung durch SKAFFON, Verifikation, Rückfallplan vor Umsetzung.

  • Sicherheitsupdate

    Beobachtung von Sicherheitsmeldungen zu Kubernetes, Treibern, Operator und Betriebssystem; Bewertung, Test, Rollout nach dem Update-Verfahren. Dringende Updates stimmen wir außerhalb des Regelzyklus ab.

09Wiederherstellung

Ein Backup zählt erst, wenn der Restore getestet ist

Velero sichert Cluster-Ressourcen und je nach Speicherlösung Volume-Snapshots. Ein Backup gilt erst durch einen Restore-Test als belegt. RPO/RTO werden je Vertrag vereinbart und per Restore-Test nachgewiesen.

Große Modellartefakte sichern wir getrennt vom Cluster-Backup, weil Volume-Snapshots dafür selten das passende Werkzeug sind.

10Einstieg

Vom Bestandscluster zum Regelbetrieb

  1. 01

    Bestandsaufnahme

    Versionen, Operator, Treiber, Netzwerk, Workloads, Risiken.

  2. 02

    Betriebsplan

    RACI und Wartungsfenster festlegen.

  3. 03

    Konfiguration nach Git

    Überführung der bestehenden Konfiguration in das Repository.

  4. 04

    Monitoring und Backup aufschalten

    Dazu Probealarm und Restore-Test.

  5. 05

    Regelbetrieb

    Betrieb nach Plan, mit regelmäßigem Betriebsbericht.

11Abgrenzung

Wofür der GPU-Betrieb gedacht ist und wofür nicht

Das übernehmen wir

  • Plattformebene: Nodes, Operator, Treiber, Netzwerk, Storage, Monitoring, Backup.
  • Betrieb eines GPU-Clusters, den Sie oder ein Dritter aufgebaut hat, nach Bestandsaufnahme.
  • Modelle und Anwendungen auf der Plattform (Serving-Software, Modellauswahl, Prompting) nur, wenn ausdrücklich beauftragt; siehe LLM Inference und KI-Sicherheit.

Das gehört nicht dazu

  • Modelltraining, Modellqualität, Trainingsdaten oder Data-Science-Ergebnisse.
  • Hardware, Rechenzentrum und Herstellergarantie bei eigenem Cluster; bei Cloud-GPUs gelten die Bedingungen des Anbieters.
  • Hardware-Wartung im Rechenzentrum: Sie liegt beim Rechenzentrumsbetreiber oder Hardwarelieferanten.
  • Ein einzelner GPU-Server ohne Betriebsanforderungen.
  • Ein Cluster ohne Zugang und Dokumentation.

12Angebot

Verfügbarkeitsziele nach Ihrer Topologie

Was ein GPU-Cluster zusichern kann, hängt von der Topologie ab: von der Zahl der GPU-Server, von Reserve-Kapazität und davon, ob Dienste über mehrere Server verteilt sind. Kennzahlen, Messmethode und Folgen bei Abweichung werden vertraglich vereinbart; die Systematik beschreibt der Servicelevel-Rahmen.

Den Aufwand bestimmen die Zahl der Cluster und GPU-Pools, GPU-Klassen und -Anzahl, Zahl der Teams und Umgebungen, Anforderungen an Verfügbarkeit und Wiederherstellung, Änderungsvolumen und das gewünschte Servicefenster. Wir beginnen mit der Bestandsaufnahme und legen daraus Umfang, RACI und Berichtsrhythmus fest; das Angebot nennt Annahmen und Preismodell.

13

Häufige Fragen

Betreiben Sie auch Cluster, die Sie nicht gebaut haben?

Ja, nach einer Bestandsaufnahme.

Was passiert, wenn eine GPU ausfällt?

Auf Plattformebene erkennen wir den Ausfall über das GPU-Monitoring, grenzen ihn ein (GPU, Node, Operator, Netzwerk) und tauschen oder isolieren den Node. Ist die Hardware defekt, liegt der Tausch laut Matrix beim Hardware-Verantwortlichen; bei Cloud-GPUs gelten die Bedingungen des Anbieters.

Wer entscheidet, wann Treiber und Operator aktualisiert werden?

Sie geben das Wartungsfenster frei, SKAFFON führt das Update nach dem Acht-Schritte-Verfahren aus. Dringende Sicherheitsupdates stimmen wir außerhalb des Regelzyklus ab.

Woher kommt die GPU-Kapazität?

SKAFFON besitzt keine eigenen GPUs. Die Kapazität kommt von Cloud-Anbietern wie STACKIT oder IONOS oder aus Ihrer eigenen Hardware. Die Zuständigkeiten für Beschaffung und Hardware stehen in der Verantwortungsmatrix.

Betrieb übergeben

Beschreiben Sie Ihren GPU-Cluster

Schildern Sie Cluster, GPU-Klassen und Ihre Betriebsanforderungen. Fragen vorab über den Kontakt.

Projekt anfragen Kontakt