Mise à l'échelle sans redémarrage : Redimensionnement in-place des Pods Kubernetes et DRA pour les ponts de simulation à état

Killer et reprogrammer un pod juste pour lui accorder plus de mémoire GPU est une perturbation catastrophique pour les ponts de rendu en temps réel à état. Voici un guide sur comment Kubernetes’ In-Place Pod Resize (stable depuis la v1.35) et Dynamic Resource Allocation (stable depuis la v1.34, et toujours en expansion en v1.36) permettent de faire évoluer les pipelines de réseau spatial verticalement sans perdre de frames — et où se trouvent encore les imperfections.

Introduction : La perturbation à haut risque du reprogrammation de Pod

La simulation 3D en temps réel et la synchronisation des jumeaux numériques sont devenues des charges de travail critiques dans l’informatique industrielle. Des plateformes comme NVIDIA Omniverse sont utilisées pour créer des répliques numériques haute fidélité de sols d’usine, hubs logistiques et systèmes aérospatiaux, ces environnements étant fortement à état — ils traitent des flux continus de télémétrie spatiale et de données dense en nuages de points.

Pour connecter le matériel physique aux moteurs de simulation cloud, les équipes exécutent souvent des pods de routage de données localisés — “ponts de simulation” — dans des clusters Kubernetes cloud ou edge. Ces ponts maintiennent des connexions WebSocket ou gRPC longues, tamponnent des séquences de frames en mémoire, et utilisent souvent l’accélération GPU locale pour décomposer ou pré-rendre des données CAD/nuages de points denses avant de les transmettre à un environnement de visualisation centralisé.

Historiquement, si un pod de pont rencontrait ses limites de ressources, Kubernetes n’avait qu’un seul outil : évincer et reprogrammer. Un autoscaler vertical ou un opérateur devait tuer le pod, trouver un nœud avec capacité disponible, remonter les volumes, et relancer le conteneur. Pour un service web sans état, c’est une petite perturbation. Pour un pont de simulation à état, c’est disruptif de plusieurs façons concrètes :

• Tunnels cassés — les sessions TCP/WebSocket en direct avec des capteurs physiques tombent instantanément, déclenchant des cascades de timeout sur les appareils en edge.
• Invalidation du cache — les buffers de frames en mémoire et les index spatiaux sont effacés, nécessitant une réinitialisation lente.
• Stuttering visuel — la synchronisation du rendu en temps réel se fige ou perd des frames pour les opérateurs humains et les systèmes d’inspection automatisés.

Deux fonctionnalités Kubernetes comblent cette lacune : In-Place Pod Resize (mutation du CPU/mémoire du conteneur sans redémarrage) et Dynamic Resource Allocation, ou DRA (claims de périphériques matériels basés sur des attributs qui ne nécessitent pas la recréation du pod pour changer). Aucune n’est nouvelle, et connaître l’historique des versions est important si vous planifiez une mise en production — voici où en sont réellement les choses.

Obtenir la chronologie correcte

Il est utile d’être précis sur quand chaque fonctionnalité s’est stabilisée, car ces deux fonctionnalités ont été graduées dans des versions différentes, pas ensemble comme un seul package :

Fonctionnalité	Alpha	Bêta	Stable (GA)
In-Place Pod Resize (niveau conteneur, KEP-1287)	v1.27 (2023)	v1.33 (mai 2025)	v1.35 (17 déc. 2025)
Dynamic Resource Allocation (core, resource.k8s.io/v1)	v1.26	v1.32–1.33	v1.34 (août/sept. 2025)
Redimensionnement in-place (niveau pod, KEP-5419)	v1.35	v1.36 (22 avril 2026)	— (encore en bêta)

Ainsi, lorsque Kubernetes 1.35 (“Timbernetes”) a été publié, DRA était déjà en GA depuis une version. Ce que la 1.35 a réellement livré, c’est la graduation du resize in-place vers la stabilité, en s’appuyant sur une base DRA déjà stable — deux fonctionnalités complémentaires, mais sur des timelines séparées. La version 1.35 a aussi levé une restriction de longue date : les diminutions de limite mémoire, qui étaient auparavant interdites, sont maintenant autorisées, sous réserve d’une vérification de kubelet en mode best-effort contre l’usage actuel.

La dernière version Kubernetes au moment de cette rédaction est v1.36 (“Haru”), sortie le 22 avril 2026, qui étend davantage ces fonctionnalités — abordées vers la fin de cet article.

Le rôle de cgroups v2

Le redimensionnement in-place dépend de l’unification de la hiérarchie cgroups v2 du noyau Linux, qui permet au kubelet de réécrire les limites de ressources (cpu.max, memory.max) d’un cgroup en cours d’exécution sans envoyer de signal de terminaison. Le noyau applique la nouvelle limite immédiatement ; le PID du processus, les sockets ouverts, et l’état en mémoire restent inchangés.

Le scheduling GPU traditionnel, en revanche, reposait sur le modèle Device Plugin, qui demande des GPU sous forme de comptages entiers (nvidia.com/gpu: 1). Il n’est pas possible de demander une augmentation fractionnaire de VRAM ou de changer un profil de périphérique sans détruire le pod — c’est le vide que DRA comble.

Analyse approfondie : Mécanismes du redimensionnement in-place des Pods

La sous-ressource resize, pas un PATCH brut

Une correction importante : un redimensionnement in-place n’est pas appliqué via un PATCH générique sur l’objet pod. Kubernetes expose cela comme une sous-ressource /resize dédiée, et kubectl doit être en v1.32 ou supérieur pour l’utiliser :

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"}
  ]'

Le routage via leur propre sous-ressource a aussi une implication opérationnelle : cela signifie que vous pouvez accorder un verbe patch sur pods/resize à un contrôleur d’autoscaling sans lui donner accès en écriture au reste du spec du pod — une surface RBAC plus restreinte qu’un permission de mise à jour globale du pod.

Comment Kubernetes suit un resize

Le cycle de vie est suivi via des champs et conditions du statut du pod, pas un seul enum de haut niveau :

Champ / Condition	Signification
spec.containers[*].resources	Ressources désirées — ce que vous avez demandé.
status.containerStatuses[*].resources	Ressources actuelles/allocées appliquées au conteneur en cours d’exécution.
PodResizePending (raison : Deferred)	Le nœud manque temporairement de capacité ; kubelet réessaiera.
PodResizePending (raison : Infeasible)	La requête ne peut jamais être satisfaite sur ce nœud (par ex., dépasse la capacité totale, ou le pod utilise une politique de gestion CPU/mémoire statique). Le pod continue à fonctionner avec l’allocation précédente.
PodResizeInProgress	Le kubelet a accepté le resize et l’applique activement.

Immuabilité de la classe QoS

La classe QoS d’un pod (Guaranteed, Burstable, BestEffort) est calculée à partir de la relation entre demandes et limites, et elle ne peut pas changer suite à un resize — c’est une des non-objectifs explicites de KEP-1287. Si un pod de pont Guaranteed (demandes == limites) voit sa limite patchée sans changement équivalent dans sa demande, le serveur API rejette le patch. Il faut faire évoluer les deux champs ensemble.

La garde-fou du downscaling

Avant la sortie GA, diminuer une limite mémoire était bloqué purement. Depuis v1.35, les diminutions sont autorisées, mais le kubelet effectue une vérification de sécurité en mode best-effort : il lit l’usage mémoire actuel du conteneur via les statistiques cgroups avant de valider une limite inférieure. Si l’usage dépasse la nouvelle limite proposée, le kubelet maintient le resize en PodResizePending (raison Deferred) plutôt que risquer une OOM-kill. Cette vérification n’est pas garantie — c’est une course entre le moment de la vérification et l’utilisation, donc il faut rester prudent lors de downscaling agressif sur des charges à empreinte mémoire volatile (comme un pont de simulation en pleine rafale).

Quand un nœud ne peut satisfaire toutes les demandes de resize en attente, celles en attente sont réessayées selon un ordre de priorité : d’abord par PriorityClass, puis par classe QoS (Guaranteed avant Burstable), et enfin par durée d’attente.

Analyse approfondie : Allocation dynamique de ressources pour GPU

Les API principales de DRA résident toutes dans le groupe API stable resource.k8s.io/v1 (pas v1alpha3, qui était la version pré-GA utilisée lors de la période bêta 1.32–1.33) :

• DeviceClass — une définition à l’échelle du cluster (créée par les administrateurs ou vendeurs de périphériques) qui classe un pool de matériel via des expressions CEL (Common Expression Language) — par exemple, correspondant à des appareils où device.driver == "gpu.nvidia.com".
• ResourceSlice — un inventaire en direct publié par le pilote de périphérique par nœud, décrivant les appareils disponibles, leurs attributs, et leur capacité.
• ResourceClaim — l’équivalent du PersistentVolumeClaim pour le périphérique : une demande concrète pour du matériel correspondant à un DeviceClass, avec un cycle de vie indépendant d’un seul pod.
• ResourceClaimTemplate — intégré dans le spec d’un pod pour que Kubernetes génère automatiquement un ResourceClaim dédié par instance de pod et le détruise à la fin du pod.

Comparaison architecturale

	Ancien plugin de périphériques	DRA (resource.k8s.io/v1)
Attribution	Comptages entiers (nvidia.com/gpu: 1)	Basée sur attributs (VRAM, profil MIG, pilote, topologie) via CEL
Reconfiguration en direct	Nécessite la recréation complète du pod	Les claims peuvent être mis à jour via un modèle de template ; nouveaux claims peuvent être résolus sans toucher aux autres champs du pod
Partage de périphériques	Hacks statiques, spécifiques au vendeur	Partage natif (et, depuis v1.36 bêta, partition GPU native)

Architecturer un pont de simulation sans interruption

Voici un manifeste corrigé utilisant le schéma DRA stable (notez le bloc exactly: entourant deviceClassName et selectors, requis par l’API stable actuelle) :

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

      # Contrôle si un changement de ressource force un redémarrage du conteneur
      resizePolicy:
        - resourceName: cpu
          restartPolicy: NotRequired
        - resourceName: memory
          restartPolicy: NotRequired

      # Ressources de base — QoS Garanties (demandes == limites)
      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"

Pour faire évoluer ce pod, un contrôleur d’autoscaling envoie un patch JSON contre la sous-ressource /resize du pod (comme montré ci-dessus), tout en mettant à jour séparément le ResourceClaim associé pour demander un profil MIG plus grand. Le kubelet vérifie la capacité CPU/mémoire non allouée du nœud, coordonne avec le pilote DRA via gRPC pour remapper le périphérique GPU, et met à jour les limites cgroup — tout en maintenant la lecture en continu de la boucle WebSocket de spatial-router-container.

Cas d’usage en production et garde-fous

Capacité différée. Si un nœud est presque saturé, une demande de resize reste en PodResizePending (Deferred) jusqu’à ce que la capacité se libère — réessayée automatiquement selon l’ordre de priorité décrit ci-dessus, mais sans délai garanti. Pour un pont sensible à la latence, il est judicieux de définir un seuil de secours (par ex., une migration manuelle si un resize est différé depuis plus de quelques secondes) plutôt que de faire confiance à une attente indéfinie lors d’un pic de charge.

Dérive du contrôleur/spec. Un resize appliqué directement via la sous-ressource /resize ne met pas à jour le Deployment ou StatefulSet propriétaire du pod. Si le nœud échoue plus tard et que le contrôleur reprogrammera un remplacement, il créera un pod avec le profil de ressources original, non redimensionné. Les configurations en production associent généralement le redimensionnement in-place à un VPA en mode InPlaceOrRecreate (bêta, basé sur KEP-1287) ou à un opérateur personnalisé qui reflète le resize appliqué dans une annotation, pour que le remplacement reprogrammé démarre avec la bonne taille.

Politiques statiques de gestion des ressources. Le redimensionnement d’un pod Guaranteed QoS est explicitement hors du scope de KEP-1287 lorsque le nœud utilise une politique de gestion CPU/mémoire statique (pour épingler des cœurs ou mémoire NUMA exclusifs à un pod) — ce resize est rejeté comme Infeasible. Si vos nœuds de pont utilisent le pinning CPU statique pour des charges sensibles au jitter, planifiez en conséquence plutôt que d’attendre une compatibilité universelle ; des discussions communautaires évoquent un futur support pour cette combinaison, mais ce n’est pas dans la version stable à ce jour (v1.36).

Quoi de neuf depuis la GA : Kubernetes v1.36 (“Haru”, avril 2026)

Depuis la mise en GA de cette stack, la version suivante (v1.36, sortie le 22 avril 2026 et la branche stable actuelle à mi-2026) a poussé ces deux fonctionnalités plus loin — pertinent si vous concevez une architecture de pont aujourd’hui plutôt qu’en décembre 2025 :

• Redimensionnement in-place au niveau pod (bêta, activé par défaut, nécessite cgroups v2) étend le redimensionnement du conteneur individuel à l’enveloppe de ressources du pod, contrôlé par quatre flags de fonctionnalités (PodLevelResources, InPlacePodVerticalScaling, InPlacePodLevelResourcesVerticalScaling, NodeDeclaredFeatures). Utile pour des pods de pont multi-conteneurs (par ex., un conteneur de routage plus un sidecar de télémétrie) où vous souhaitez faire évoluer un budget de ressources partagé plutôt que chaque conteneur séparément.
• Périphériques partitionables et capacité consommable dans DRA passés en bêta et activés par défaut — c’est l’équivalent natif de demander manuellement des slices MIG via des sélecteurs CEL comme dans le manifeste ci-dessus, permettant à DRA de comprendre directement les partitions GPU plutôt que de traiter une slice MIG comme un périphérique opaque.
• Taints et tolerations de périphériques (bêta) permettent à un pilote DRA de marquer un GPU dégradé directement dans son ResourceSlice (par ex., après une erreur ECC), évitant ainsi de le faire apparaître dans l’inventaire sans que le pilote doive le retirer complètement.
• État de santé des ressources pour les Pods (allocatedResourcesStatus, bêta) remonte la santé par périphérique directement dans le statut du pod et via kubectl describe pod — utile pour distinguer “le conteneur du pont a planté” de “le GPU qui lui a été alloué est en mauvais état”, à la fois pour DRA et les plugins legacy.

Aucun de ces changements ne modifie l’architecture décrite ci-dessus, mais les fonctionnalités de statut de santé et de taint de périphériques comblent une vraie lacune d’observabilité pour ce type de pont GPU sensible à la latence : vous pouvez désormais savoir qu’un périphérique se dégrade avant qu’il ne force une migration imprévue.

Conclusion

In-Place Pod Resize (GA en v1.35) et Dynamic Resource Allocation (GA en v1.34) — sortis à un cycle d’intervalle, pas simultanément — éliminent ensemble la nécessité de détruire un pod pour changer son empreinte de ressources, CPU/mémoire ou GPU. Pour les ponts de simulation à état avec état WebSocket/gRPC en direct, c’est la différence entre un pipeline en direct qui s’adapte à la charge et un qui perd des connexions à chaque surcharge. La mécanique a son importance : les redimensionnements passent par une sous-ressource /resize dédiée, la classe QoS est immuable, la réduction de mémoire est vérifiée mais pas garantie sûre, et le pinning CPU/mémoire statique reste une limite explicite. Construire autour de ces contraintes — plutôt que d’attendre une version idéale de la fonctionnalité — c’est ce qui permet à une architecture sans redémarrage d’être réellement sans redémarrage en production.

---

Journal des modifications

Corrections apportées à la version initiale : 1. La sortie GA de DRA était la v1.34, pas la v1.35. La draft laissait entendre que DRA “a atteint la stabilité complète en même temps que la v1.35.” La core (resource.k8s.io/v1) de DRA est en GA depuis Kubernetes 1.34 (août/sept. 2025) ; la v1.35 (déc. 2025) correspond à la mise en GA de l’In-Place Pod Resize (KEP-1287). Ajout d’un tableau d’historique pour clarifier. 2. Correction du mécanisme API de resize. L’exemple JSON patch initial modifiait directement l’objet pod. Kubernetes requiert que le resize passe par la sous-ressource /resize dédiée (kubectl patch --subresource resize, version v1.32+). Mise à jour de l’exemple et ajout de l’implication RBAC. 3. Correction du modèle de statut du pod. Le tableau laissait entendre que Allocated, Resources, PodResizePending, et Infeasible étaient des champs parallèles de haut niveau. En réalité : les ressources désirées/actuelles vivent dans spec/status.containerStatuses, et Deferred/Infeasible sont raisons sur la condition PodResizePending, avec PodResizeInProgress comme condition séparée. Refonte du tableau. 4. Correction de la version API du manifeste DRA. La YAML initiale utilisait resource.k8s.io/v1alpha3, une version pré-GA. Mise à jour vers resource.k8s.io/v1, incluant le wrapper exactly: requis par l’API actuelle. 5. Ajout de la modification mémoire et de la priorité de réessai du resize — toutes deux nouvelles en GA v1.35, non mentionnées dans la draft. 6. Nuance sur la limitation des politiques statiques. La réduction mémoire pour un pod Guaranteed est explicitement hors scope de KEP-1287 quand le nœud utilise une politique statique (rejetée comme Infeasible). La planification doit en tenir compte, car cela reste une limite connue. 7. Section “Quoi de neuf en v1.36” ajoutée, couvrant le resize au niveau pod (bêta), périphériques partitionnables, taints/tolerations, et état de santé DRA — puisque v1.36 (“Haru,” avril 2026) est la version stable actuelle. 8. Suppression des artefacts SEO/IA et reformattage pour une meilleure lisibilité.

Sources principales consultées : - Kubernetes 1.35 : In-Place Pod Resize en GA - Redimensionner CPU et mémoire des conteneurs - Redimensionner CPU et mémoire des Pods - Mise à jour in-place des ressources du Pod, KEP-1287 - Kubernetes v1.34 : DRA en GA - Allocation dynamique de ressources - Allouer des périphériques aux charges de travail avec DRA - Kubernetes v1.36 : ハル (Haru) - Kubernetes v1.36 : Nouveautés, APIs stables & changements majeurs - Releases Kubernetes — matrice de versions/support