Zero-Restart Skalierung: Kubernetes In-Place Pod-Resize und DRA für zustandsbehaftete Simulationsbrücken

Killing und Neuplanung eines Pods nur um ihm mehr GPU-Speicher zuzuweisen, ist eine katastrophale Störung für zustandsbehaftete, Echtzeit-Rendering-Brücken. Dieser Leitfaden erklärt, wie Kubernetes’ In-Place Pod Resize (stabil seit v1.35) und Dynamic Resource Allocation (stabil seit v1.34, und noch in Erweiterung in v1.36) es ermöglichen, räumliche Netzwerke-Pipelines vertikal zu skalieren, ohne Frames zu verlieren — und wo noch Verbesserungsbedarf besteht.

Einführung: Die Hochrisiko-Unterbrechung durch Pod-Neuplanung

Echtzeit-3D-Simulationen und die Synchronisation digitaler Zwillinge sind zu kritischen Workloads in der industriellen Datenverarbeitung geworden. Plattformen wie NVIDIA Omniverse werden genutzt, um hochpräzise digitale Repliken von Fabrikflächen, Logistikzentren und Luftfahrtsystemen zu erstellen. Diese Umgebungen sind hochzustaatlich — sie verarbeiten kontinuierliche Ströme räumlicher Telemetrie und dichte Punktwolken-Daten.

Um physische Hardware mit cloud-basierten Simulations-Engines zu verbinden, betreiben Teams häufig lokalisierte Daten-Routing-Pods — “Simulationsbrücken” — innerhalb von Cloud- oder Edge-Kubernetes-Clustern. Diese Brücken halten langlebige WebSocket- oder gRPC-Verbindungen, puffern Frame-Sequenzen im Speicher und nutzen oft lokale GPU-Beschleunigung, um dichte CAD- oder Punktwolken-Daten vorzuskalieren oder vor-rendern, bevor sie an eine zentrale Visualisierungsumgebung weitergeleitet werden.

Historisch gesehen gab es bei Ressourcenüberschreitungen nur eine Lösung: evict und neu planen. Ein vertikaler Autoscaler oder Operator musste den Pod killen, einen Knoten mit freier Kapazität finden, Volumes neu mounten und den Container wieder starten. Für einen stateless Web-Service ist das nur eine kleine Unterbrechung. Für eine zustandsbehaftete Simulationsbrücke ist es jedoch in mehreren konkreten Punkten störend:

• Gebrochene Tunnel — Live TCP/WebSocket-Sitzungen zu physischen Sensoren brechen sofort ab, was Timeout-Kaskaden auf Edge-Geräten auslöst.
• Cache-Invalidierung — In-Memory-Framepuffer und räumliche Indizes werden gelöscht, was eine langsame Reinitialisierung erzwingt.
• Visuelles Stottern — Echtzeit-Rendering-Synchronisation friert ein oder droppt Frames, was menschliche Operatoren und automatisierte Inspektionssysteme beeinträchtigt.

Zwei Kubernetes-Features schließen diese Lücke: In-Place Pod Resize (Container-CPU/Mem-Änderung ohne Neustart) und Dynamic Resource Allocation oder DRA (attributbasierte Hardware-Geräteansprüche, die keine Pod-Neuerstellung erfordern). Beide sind nicht mehr ganz neu, und die Versionsgeschichte ist wichtig, wenn man eine Produktions-Implementierung plant — hier ist der aktuelle Stand.

Die Timeline richtig verstehen

Es lohnt sich, genau zu wissen, wann welche Funktion stabil wurde, da diese beiden Features in unterschiedlichen Releases eingeführt wurden, nicht zusammen als Paket:

Feature	Alpha	Beta	Stabil (GA)
In-Place Pod Resize (container-level, KEP-1287)	v1.27 (2023)	v1.33 (Mai 2025)	v1.35 (Dez 17, 2025)
Dynamic Resource Allocation (core, resource.k8s.io/v1)	v1.26	v1.32–1.33	v1.34 (Aug/Sep 2025)
In-place Pod-level resize (aggregierte Ressourcen, KEP-5419)	v1.35	v1.36 (22. April 2026)	— (noch Beta)

Bis Kubernetes 1.35 (“Timbernetes”) ausgeliefert wurde, war DRA bereits in GA. Was v1.35 brachte, war die Freigabe des in-place resize, basierend auf einer bereits stabilen DRA-Grundlage — die beiden Features ergänzen sich, aber auf unterschiedlichen Zeitachsen. Das v1.35-Release hob auch eine langjährige Einschränkung auf: Memory-Limit-Reduktionen, die vorher komplett verboten waren, sind jetzt erlaubt, gesteuert durch eine Best-Effort-Check des kubelet gegen die aktuelle Nutzung.

Das neueste Kubernetes-Release zum Zeitpunkt dieses Schreibens ist v1.36 (“Haru”), ausgeliefert am 22. April 2026, das beide Features weiter ausbaut — dazu später mehr.

Die Rolle von cgroups v2

In-place Resize basiert auf der Linux-Kernel-eigenen cgroups v2-Hierarchie, die es dem kubelet erlaubt, Ressourcen-Grenzen (cpu.max, memory.max) eines laufenden Prozesses zu überschreiben, ohne das Signal zum Beenden zu schicken. Der Kernel setzt die neuen Grenzen sofort um; die PID, offene Sockets und der Speicherzustand bleiben unberührt.

Traditionelle GPU-Planung nutzte das Device Plugin-Modell, das GPUs als undurchsichtige Integer-Anzahl (nvidia.com/gpu: 1) anfragt. Es ist nicht möglich, eine Bruchteilige VRAM-Erhöhung oder ein Device-Profil zu fordern, ohne den Pod komplett zu zerstören — genau das schließt DRA.

Deep-Dive: Wie funktioniert das In-Place Pod-Resize?

Das Resize-Subresource, kein reines PATCH

Eine wichtige Korrektur vorweg: Ein In-Place-Resize wird nicht durch einen generischen PATCH am Pod-Objekt durchgeführt. Kubernetes stellt dafür ein spezielles /resize-Subresource bereit, das kubectl ab Version v1.32 nutzen muss:

kubectl patch pod omniverse-local-bridge \
  --subresource resize \
  --type='json' \
  -p='[
    {"op": "replace", "path": "/spec/containers/0/resources/requests/cpu", "value": "8"},
    {"op": "replace", "path": "/spec/containers/0/resources/limits/cpu", "value": "8"},
    {"op": "replace", "path": "/spec/containers/0/resources/requests/memory", "value": "32Gi"},
    {"op": "replace", "path": "/spec/containers/0/resources/limits/memory", "value": "32Gi"}
  ]'

Das Routing der Resizes über das eigene Subresource ist auch operational relevant: Es erlaubt, einem Autoscaler-Controller das patch-Recht auf pods/resize zu geben, ohne Schreibzugriff auf den Rest des Pod-Objekts — eine deutlich engere RBAC-Beschränkung als ein generelles Pod-Update.

Wie Kubernetes einen Resize verfolgt

Der Lebenszyklus wird durch Statusfelder und Bedingungen im Pod verfolgt, nicht durch eine einzelne Top-Level-Enum:

Feld / Bedingung	Bedeutung
spec.containers[*].resources	Gewünschte Ressourcen — was angefragt wurde.
status.containerStatuses[*].resources	Aktuelle/zugewiesene Ressourcen, die momentan im Container gelten.
PodResizePending (Grund: Deferred)	Node hat vorübergehend keine Kapazität; kubelet versucht es erneut.
PodResizePending (Grund: Infeasible)	Die Anfrage kann auf diesem Node nie erfüllt werden (z.B. überschreitet die Kapazität, oder der Pod nutzt einen statischen CPU/memory-Manager). Der Pod läuft weiterhin mit der vorherigen Zuweisung.
PodResizeInProgress	Kubelet hat den Resize akzeptiert und arbeitet aktiv daran.

QoS-Klassen-Unveränderlichkeit

Die QoS-Klasse eines Pods (Guaranteed, Burstable, BestEffort) ergibt sich aus der Beziehung zwischen Requests und Limits und kann sich durch einen Resize nicht ändern — das ist eine der expliziten Nicht-Ziele von KEP-1287. Wenn ein Guaranteed-Pod (Requests == Limits) ohne gleichzeitige Änderung der Requests das Limit patcht, wird das vom API-Server abgelehnt. Beide Felder müssen zusammen angepasst werden.

Die Downscaling-Schutzvorrichtung

Vor dem GA-Release war eine Memory-Limit-Reduktion komplett blockiert. Mit v1.35 sind Reduktionen erlaubt, aber der kubelet führt eine Best-Effort-Sicherheitsprüfung durch: Es liest die aktuelle Speicherbelegung des Containers via cgroup-Statistiken, bevor es ein niedrigeres memory.max setzt. Wenn die Nutzung das vorgeschlagene Limit übersteigt, hält der kubelet den Resize in PodResizePending (Deferred) anstatt ein Out-of-Memory-Kill zu riskieren. Diese Prüfung ist explizit nicht garantiert — es besteht ein Race zwischen Check und Anwendung, weshalb bei Workloads mit volatilen Speicheranforderungen (z.B. eine Simulation im Burst) Vorsicht geboten ist.

Wenn ein Node nicht alle pending Resizes gleichzeitig erfüllen kann, werden die verzögerten Anfragen nach Priorität erneut versucht: zuerst nach PriorityClass, dann nach QoS-Klasse (Guaranteed vor Burstable), und schließlich nach Wartezeit.

Deep-Dive: DRA für GPUs

DRA’s Kern-APIs laufen alle unter der stabilen resource.k8s.io/v1 API-Gruppe (nicht v1alpha3, die vor GA genutzt wurde):

• DeviceClass — eine clusterweite Definition (erstellt von Admins oder Geräteherstellern), die eine Hardware-Pool klassifiziert mittels CEL (Common Expression Language) — z.B. Geräte, bei denen device.driver == "gpu.nvidia.com".
• ResourceSlice — eine laufende Inventarliste pro Node, vom Geräte-Treiber veröffentlicht, mit verfügbaren Geräten, Attributen und Kapazität.
• ResourceClaim — das Geräte-Äquivalent eines PersistentVolumeClaim: eine konkrete Anfrage nach Hardware, passend zu einem DeviceClass, mit eigenem Lebenszyklus, unabhängig von einzelnen Pods.
• ResourceClaimTemplate — in einem Pod-Spec eingebettet, damit Kubernetes automatisch einen dedizierten ResourceClaim pro Pod generiert und beim Beenden wieder entfernt.

Architekturvergleich

	Legacy Device Plugins	DRA (resource.k8s.io/v1)
Zuweisung	Ganze Geräte, z.B. nvidia.com/gpu: 1	Attributbasiert (VRAM, MIG-Profil, Treiber, Topologie) via CEL
Re-Konfiguration im laufenden Betrieb	Erfordert Pod-Neuplanung	Claims können auf Template-Basis aktualisiert werden; neue Claims ohne Änderungen an anderen Pod-Feldern
Geräte-Sharing	Statisch, vendor-spezifisch	Native Sharing (und seit v1.36 Beta: native GPU-Partitionierung)

Architektur eines Zero-Downtime Simulationsbrücke

Hier ein korrigiertes Manifest unter Verwendung des stabilen DRA-Schemas (beachten Sie den exactly:-Block um deviceClassName und selectors, der vom aktuellen API-Stand verlangt wird):

apiVersion: v1
kind: Pod
metadata:
  name: omniverse-local-bridge
  namespace: spatial-net
  labels:
    app: simulation-pipeline
spec:
  resourceClaims:
    - name: dynamic-gpu-allocation
      resourceClaimTemplateName: omniverse-gpu-template

  containers:
    - name: spatial-router-container
      image: cr.enterprise.internal/spatial/omniverse-bridge:v2026.2.1
      imagePullPolicy: IfNotPresent

      # Steuerung, ob eine Ressourcenänderung einen Container-Neustart erzwingt
      resizePolicy:
        - resourceName: cpu
          restartPolicy: NotRequired
        - resourceName: memory
          restartPolicy: NotRequired

      # Basisressourcen — Guaranteed QoS (Requests == Limits)
      resources:
        requests:
          cpu: "4"
          memory: "16Gi"
        limits:
          cpu: "4"
          memory: "16Gi"

      claims:
        - name: dynamic-gpu-allocation

      ports:
        - containerPort: 8080
          name: websocket-sync
        - containerPort: 9090
          name: grpc-telemetry
---
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: omniverse-gpu-template
  namespace: spatial-net
spec:
  spec:
    devices:
      requests:
        - name: primary-rendering-core
          exactly:
            deviceClassName: enterprise-nvidia-gpu
            selectors:
              - cel:
                  expression: |-
                    device.attributes["gpu.nvidia.com"].profile == "1g.5gb" ||
                    device.attributes["gpu.nvidia.com"].profile == "3g.20gb"

Zur Skalierung dieses Pods sendet ein Autoscaling-Controller einen JSON-Patch gegen das /resize-Subresource des Pods (wie oben gezeigt), während er separat die zugehörige ResourceClaim aktualisiert, um ein größeres MIG-Profil anzufragen. Der kubelet prüft die ungenutzte CPU/Mem auf dem Node, koordiniert mit dem DRA-Treiber über gRPC, um das GPU-Gerät neu zuzuordnen, und aktualisiert die cgroup-Grenzen — alles, während die WebSocket-Schleife im spatial-router-container ununterbrochen liest.

Produktion: Edge-Fälle und Schutzmaßnahmen

Verzögerte Kapazität. Wenn ein Node fast voll ausgelastet ist, verbleibt eine Resize-Anfrage in PodResizePending (Deferred) bis Kapazität frei wird — wird automatisch nach der oben beschriebenen Priorität erneut versucht, aber ohne garantierte Zeitbindung. Für eine latenzkritische Brücke ist es sinnvoll, eine Fallback-Grenze zu setzen (z.B. eine manuelle Migration, wenn eine Resize-Anfrage länger als einige Sekunden verzögert wird), anstatt auf eine offene Wartezeit zu vertrauen.

Controller/Abweichung vom Spezifikations-Stand. Ein direkt über /resize angewandter Resize ändert nicht das Pod-Template im Deployment oder StatefulSet. Wenn der Node später ausfällt und der Controller eine Ersatz-Pod startet, wird dieser mit dem ursprünglichen, un-skalierten Ressourcenprofil erzeugt. Produktionsumgebungen koppeln daher in-place Resizing meist mit einem VPA im InPlaceOrRecreate-Modus (Beta, basierend auf KEP-1287) oder einem eigenen Operator, der die Änderungen im Controller via Annotation widerspiegelt, damit eine erneute Planung mit den richtigen Ressourcen erfolgt.

Statische Ressourcen-Manager-Policies. Das Resize eines Guaranteed-QoS-Pods ist explizit außerhalb des Geltungsbereichs von KEP-1287, wenn der Node einen statischen CPU- oder Memory-Manager-Policy nutzt (z.B. zum Pinning von Cores/NUMA-Memory). Solche Resizes werden als Infeasible abgelehnt. Wenn Ihre Brücken-Knoten statisches CPU-Pinning verwenden, planen Sie entsprechend, da in-place Resize hier nicht gilt; zukünftige Unterstützung wird diskutiert, ist aber in v1.36 noch nicht enthalten.

Neu seit GA: Kubernetes v1.36 (“Haru”, April 2026)

Seit der ursprünglichen GA-Freigabe wurden in der Version 1.36 (April 2026) weitere Features integriert — relevant, wenn Sie heute eine Brücken-Architektur entwerfen, nicht nur im Dezember 2025:

• Pod-Level In-Place Resize (Beta, standardmäßig aktiviert, erfordert cgroups v2) erweitert das Resize auf die gesamte Ressourcen-Hülle des Pods, gesteuert durch vier Feature-Flags (PodLevelResources, InPlacePodVerticalScaling, InPlacePodLevelResourcesVerticalScaling, NodeDeclaredFeatures). Besonders nützlich bei Multi-Container-Pods (z.B. Router plus Telemetrie), bei denen die gemeinsame Ressourcen-Budgetierung skaliert werden soll.
• Partitionierbare Geräte und konsumierbare Kapazität in DRA sind in Beta und standardmäßig aktiviert — das ist das native Äquivalent zum manuellen Anfordern von MIG-Slices via CEL-Selektoren im obigen Manifest, wodurch DRA GPU-Partitionen direkt versteht, anstatt MIG-Slices als undurchsichtige Geräte zu behandeln.
• Device Taints und Tolerations (Beta) erlauben es einem DRA-Treiber, eine verschlechterte GPU direkt im ResourceSlice zu markieren (z.B. nach ECC-Fehler), sodass neue Claims sie meiden, ohne das Gerät vollständig aus dem Inventar zu entfernen.
• Resource Health Status für Pods (allocatedResourcesStatus, Beta) zeigt die Gerätegesundheit direkt im Pod-Status und via kubectl describe pod — nützlich, um zwischen “Der Brücken-Container ist abgestürzt” und “Die GPU, die zugewiesen wurde, ist ungesund” zu unterscheiden, sowohl bei DRA als auch bei Legacy-Plugins.

Diese Features ändern die Kernarchitektur nicht, schließen aber eine wichtige Lücke bei der Beobachtbarkeit latenzkritischer GPU-Brücken: Sie können jetzt eine Verschlechterung eines Geräts erkennen, bevor es zu einer ungeplanten Migration kommt.

Fazit

In-Place Pod Resize (GA in v1.35) und Dynamic Resource Allocation (GA in v1.34) — jeweils in unterschiedlichen Releases, nicht gleichzeitig — ermöglichen es, einen Pod zu verändern, ohne ihn zu zerstören, sei es CPU/Mem oder GPU. Für zustandsbehaftete Simulationsbrücken mit Live-WebSocket/gRPC-Verbindungen ist das der Unterschied zwischen einer dynamisch skalierenden Pipeline und einer, die bei Lastspitzen Verbindungen verliert. Die Mechanik ist entscheidend: Resizes gehen über das spezielle /resize-Subresource, QoS-Klasse ist unveränderlich, Downscaling ist geprüft, aber nicht garantiert sicher, und statisches CPU/Mem-Pinning bleibt eine explizite Einschränkung. Das Arbeiten innerhalb dieser Grenzen — statt der idealisierten Annahme, alles sei möglich — macht eine Zero-Restart-Architektur in der Produktion tatsächlich zu einer Zero-Restart-Architektur.

---

Changelog

Korrekturen am Originalentwurf: 1. DRA GA-Release war v1.34, nicht v1.35. Der Entwurf implizierte, DRA “sei zusammen mit v1.35” stabil. Tatsächlich ging DRA im Kubernetes 1.34 (Aug/Sep 2025) GA; v1.35 (Dez 2025) ist die Version, in der In-Place Pod Resize (KEP-1287) stabil wurde. Eine Versions-Historie-Tabelle wurde ergänzt. 2. Resize-API-Mechanik korrigiert. Das ursprüngliche JSON-Patch-Beispiel patchte direkt das Pod-Objekt. Kubernetes verlangt für Resizes das spezielle /resize-Subresource (kubectl patch --subresource resize), das ab v1.32 genutzt werden muss. Das Beispiel wurde aktualisiert und die RBAC-Auswirkungen ergänzt. 3. Pod-Status-Modell korrigiert. Die Tabelle im Entwurf deutete an, Allocated, Resources, PodResizePending und Infeasible seien parallele Top-Level-Felder. In Wirklichkeit: Wunsch/aktuelle Ressourcen befinden sich in spec/status.containerStatuses, und Deferred/Infeasible sind Gründe bei der Bedingung PodResizePending, mit PodResizeInProgress als eigenständiger Bedingung. Die Tabelle wurde entsprechend angepasst. 4. DRA-Manifest-API-Version korrigiert. Das ursprüngliche YAML verwendete resource.k8s.io/v1alpha3, eine pre-GA-Version. Es wurde auf das stabile resource.k8s.io/v1 aktualisiert, inklusive des exactly:-Wrappers, den die aktuelle API verlangt. 5. Memory-Limit-Reduktion und Retry-Order ergänzt. Beide sind neu in v1.35 GA: Die Reduktion ist jetzt erlaubt; die Retry-Logik folgt Priorität (Priority Class → QoS → Wartezeit). 6. Nuance bei statischen Ressourcen-Policies ergänzt. Das Resize eines Guaranteed-Pods bei statischem CPU/Memory-Manager wird explizit als Nicht-Ziel von KEP-1287 gekennzeichnet, da es als Infeasible abgelehnt wird. Das bleibt ein offener Punkt. 7. Neues “Was ist neu in v1.36”-Kapitel: Pod-Level Resize (Beta), partitionierbare DRA-Geräte, Device Taints/Tolerations, DRA-Resource-Health-Status — seit v1.36 (“Haru”, April 2026) stabil, sechs Monate nach ursprünglicher Entwurfsfassung. 8. Aufräumen und Formatierung: Überarbeitete Markdown-Struktur, keine unnötigen SEO- oder AI-Artefakte.

Hauptquellen: - Kubernetes 1.35: In-Place Pod Resize Graduates to Stable - Resize CPU and Memory Resources assigned to Containers - Resize CPU and Memory Resources assigned to Pods - In-Place Update of Pod Resources, KEP-1287 - Kubernetes v1.34: DRA has graduated to GA - Dynamic Resource Allocation - Allocate Devices to Workloads with DRA - Kubernetes v1.36: ハル (Haru) - Kubernetes v1.36 Release: New Features, Stable APIs & Breaking Changes - Kubernetes releases