Kubernetes redémarre les Pods sans lâcher les GPU
Google décrit un redémarrage en place qui évite de recréer un Pod, utile pour les charges IA sur GPU ou TPU.
Google Open Source a publié le 18 juin une note sur une évolution de Kubernetes qui vise directement les grandes charges de calcul, notamment les entraînements et traitements IA/ML sur GPU ou TPU. Le fait central est précis : Kubernetes v1.35 introduit l’action RestartAllContainers, liée à la porte de fonctionnalité RestartAllContainersOnContainerExits, pour redémarrer tous les conteneurs d’un Pod sans détruire puis recréer le Pod lui-même. La fonctionnalité passe en bêta et est activée par défaut en v1.36, selon la note.
Le changement paraît bas niveau, mais il répond à un problème très concret. Dans Kubernetes, un Pod est l’unité qui regroupe un ou plusieurs conteneurs partageant réseau, stockage et cycle de vie. Jusqu’ici, lorsqu’un ensemble de conteneurs devait repartir proprement, il fallait souvent supprimer et recréer le Pod. Pour un service simple, cette opération est acceptable. Pour un job distribué qui occupe des accélérateurs coûteux, elle peut provoquer une nouvelle planification, une nouvelle adresse IP, des délais DNS, une pression sur le plan de contrôle et parfois la perte d’un emplacement rare sur un nœud équipé.
L’intérêt de RestartAllContainers est de garder le bac à sable du Pod en place. Le Kubelet arrête les conteneurs, relance les conteneurs d’initialisation, puis redémarre l’ensemble sans libérer l’identité d’exécution. L’adresse réseau, l’espace de noms, les volumes montés et les périphériques, dont les GPU ou TPU déjà attribués, restent associés au même Pod. Pour les charges IA, cette nuance peut éviter un effet de troupeau, lorsque des milliers de Pods échouent puis redemandent en même temps des ressources de calcul. Elle peut aussi éviter qu’un autre job prenne la place sur le nœud pendant la recréation.
La note cite plusieurs cas d’usage : un conteneur principal qui corrompt un environnement local, un sidecar de surveillance qui détecte une erreur fatale, un proxy de base de données qui laisse l’application dans un état périmé, ou un job qui doit retrouver son environnement complet sans perdre sa localité matérielle. Kubernetes ajoute aussi une condition AllContainersRestarting, visible par les outils d’observabilité, pour éviter de confondre ce redémarrage avec un nouveau déploiement. Le signal est sobre mais important : à mesure que l’IA consomme des grappes d’accélérateurs de plus en plus tendues, l’infrastructure open source progresse aussi sur les détails qui réduisent le gaspillage de calcul et rendent les pannes moins coûteuses.