Kubernetes 2026 : In-Place Pod Resizing et Sidecar Containers passent en GA — ce que ça change vraiment

Plus besoin de tuer vos pods pour changer leur RAM

Pendant des années, modifier les ressources CPU ou mémoire d’un pod Kubernetes signifiait une seule chose : le tuer et le recréer. Un redémarrage, une interruption de service, un risque de perturbation pour vos utilisateurs. En 2026, cette contrainte appartient au passé. Avec le passage en Generally Available (GA) de l’In-Place Pod Resizing et des Sidecar Containers, Kubernetes franchit un cap majeur vers une plateforme réellement élastique et opérationnellement mature. Ces deux fonctionnalités, longtemps promises, longtemps en alpha ou beta, sont maintenant stables et prêtes pour la production. Voici ce que ça change vraiment — et pourquoi vous devez adapter vos workflows dès maintenant.

In-Place Pod Resizing : comment ça fonctionne sous le capot

L’In-Place Pod Resizing permet de modifier les resources.requests et resources.limits d’un conteneur en cours d’exécution, sans redémarrer le pod. La feature repose sur une mécanique précise : lorsqu’un utilisateur ou un contrôleur (comme le Vertical Pod Autoscaler) émet une mise à jour des ressources, le kubelet intercepte la demande, négocie avec le container runtime (via CRI), et ajuste les cgroups directement sur le nœud hôte.

Kubernetes introduit pour cela deux nouveaux champs sur les conteneurs : resizePolicy, qui permet de définir par ressource si le redimensionnement nécessite ou non un redémarrage du conteneur, et allocatedResources, qui reflète l’état réel des ressources allouées au niveau du nœud. Le champ status.containerStatuses[].resources expose quant à lui les ressources actuellement observées.

Concrètement, lorsque vous augmentez la mémoire d’un conteneur, le kubelet met à jour la limite mémoire du cgroup immédiatement — le processus n’est pas interrompu. Pour le CPU, le redimensionnement est encore plus transparent, car la gestion des quotas CPU via cgroups v2 est non-destructive par nature. La documentation officielle Kubernetes détaille ce cycle de vie étendu.

Un manifest YAML concret pour tester le resize en place

Voici un exemple de Pod configuré pour tirer parti de l’In-Place Resizing, avec une politique de redimensionnement différenciée entre CPU et mémoire :

apiVersion: v1
kind: Pod
metadata:
  name: app-resizable
  namespace: production
spec:
  containers:
    - name: backend
      image: myapp:2.1.0
      resources:
        requests:
          cpu: "500m"
          memory: "512Mi"
        limits:
          cpu: "1000m"
          memory: "1Gi"
      resizePolicy:
        - resourceName: cpu
          restartPolicy: NotRequired
        - resourceName: memory
          restartPolicy: NotRequired
  restartPolicy: Always

Dans cet exemple, restartPolicy: NotRequired indique à Kubernetes que le conteneur peut absorber le changement de ressource sans redémarrage. Vous pouvez modifier ce pod via kubectl patch ou via une mise à jour de spec, et observer le champ status.containerStatuses[].resources évoluer en temps réel. Le VPA (Vertical Pod Autoscaler) peut désormais exploiter cette capacité pour ajuster les ressources de façon continue, sans les perturbations qu’il causait auparavant.

Sidecar Containers en GA : la fin du chaos des init containers

La seconde grande nouvelle de 2026 concerne les Sidecar Containers. Jusqu’ici, Kubernetes ne disposait d’aucun concept natif de sidecar : les conteneurs auxiliaires (agents de log, proxies Envoy, collecteurs de métriques) coexistaient dans le pod sans garantie sur leur ordre de démarrage ou d’arrêt. La solution de contournement consistait à utiliser des initContainers qui bloquaient jusqu’à être prêts, au prix d’une complexité croissante.

Kubernetes stabilise en 2026 une approche introduite en 1.29 : les init containers avec restartPolicy: Always. Un init container marqué de cette façon devient un sidecar natif — il démarre avant les conteneurs principaux, reste actif pendant toute la durée de vie du pod, et s’arrête après que les conteneurs principaux ont terminé leur exécution. Le kubelet gère ce cycle de vie de façon déterministe, ce qui résout l’un des problèmes les plus épineux des architectures microservices sur Kubernetes.

L’impact est significatif pour les workloads utilisant un service mesh (Istio, Linkerd) : le proxy sidecar est désormais garanti démarré avant que l’application ne commence à recevoir du trafic. Ce problème historique de Kubernetes, ouvert depuis 2015, est enfin résolu proprement.

Dynamic Resource Allocation passe en beta : ce que ça annonce

Dans l’ombre de ces deux GA, le Dynamic Resource Allocation (DRA) franchit le seuil de la beta. DRA est le mécanisme qui permet à Kubernetes de gérer des ressources hétérogènes et structurées — typiquement des GPU, des FPGAs, des accélérateurs réseau — d’une façon beaucoup plus flexible que les extended resources actuelles.

Avec DRA, un pod ne demande plus simplement nvidia.com/gpu: 1 de façon opaque. Il peut exprimer des contraintes structurées sur la ressource souhaitée : topologie NUMA, bande passante NVLink, partage entre conteneurs du même pod. Le passage en beta signifie que l’API est désormais stable par défaut dans les clusters Kubernetes 1.32+. La documentation DRA explique l’architecture complète de ce système.

Ce que ça change pour le Vertical Pod Autoscaler et la gestion des coûts

L’In-Place Pod Resizing transforme radicalement l’équation du Vertical Pod Autoscaler (VPA). Dans sa version historique, le VPA souffrait d’un défaut rédhibitoire : pour appliquer une recommandation, il devait évincé le pod et le recréer. En production, sur des workloads stateful ou des services critiques, ce comportement était souvent désactivé, limitant le VPA à un rôle consultatif.

Avec le resize en place, le VPA peut désormais ajuster les ressources de façon continue et non-perturbatrice. Les équipes platform peuvent envisager des boucles de rightsizing automatiques : surprovisionnement initial au démarrage, puis réduction progressive une fois le profil de charge établi. Pour les coûts cloud, l’impact est direct — moins de CPU et RAM alloués à des pods qui n’en ont pas besoin, sans le risque qu’un resize provoque une indisponibilité. La CNCF documente régulièrement les patterns d’optimisation des coûts cloud-native.

Compatibilité, prérequis et pièges à éviter

Avant de déployer ces fonctionnalités en production, plusieurs prérequis techniques méritent attention. L’In-Place Pod Resizing nécessite cgroups v2 sur les nœuds hôtes — la quasi-totalité des distributions Linux modernes (RHEL 9+, Ubuntu 22.04+, Debian 12+) l’activent par défaut. Vérifiez avec stat -fc %T /sys/fs/cgroup/ : la valeur cgroup2fs confirme la compatibilité.

Pour les Sidecar Containers, le principal piège concerne la migration d’init containers existants. Un init container converti en sidecar (ajout de restartPolicy: Always) change de sémantique : il ne bloque plus les conteneurs suivants une fois terminé, mais une fois prêt (readiness probe). Si votre init container n’a pas de probe définie, il passe immédiatement à l’état prêt après démarrage. Adaptez vos manifests en conséquence. Le blog officiel Kubernetes publie les notes de migration pour chaque release majeure.

Enfin, les outils d’admission (OPA/Gatekeeper, Kyverno) et les webhooks de mutation doivent être mis à jour pour comprendre les nouveaux champs resizePolicy et allocatedResources. Le dépôt principal Kubernetes sur GitHub liste les changelogs complets de chaque version.

Conclusion : ce que vous devez faire dès maintenant

Le passage en GA de l’In-Place Pod Resizing et des Sidecar Containers n’est pas un simple détail de release notes. C’est un changement de paradigme pour la façon dont vous gérez l’élasticité et la composition de vos workloads Kubernetes. Voici les trois actions concrètes à engager sans attendre :

1. Auditez vos nœuds pour cgroups v2. Identifiez les nœuds incompatibles et planifiez leur migration ou remplacement. Sans cgroups v2, l’In-Place Resizing ne fonctionnera pas.
2. Réactivez et reconfigurez votre VPA en mode auto. Avec le resize en place, les risques d’évincement non désiré disparaissent. Testez d’abord sur des namespaces non-critiques, mesurez l’impact sur vos coûts.
3. Migrez vos sidecars vers le pattern natif. Identifiez les init containers utilisés comme proxies ou agents persistants, ajoutez restartPolicy: Always, et supprimez vos scripts de synchronisation maison.

Kubernetes mature. Ces GA en 2026 le confirment : la plateforme ne se contente plus de scheduler des conteneurs — elle gère leur cycle de vie complet avec une précision croissante. Les équipes qui s’approprieront ces fonctionnalités rapidement gagneront en résilience, en efficacité opérationnelle et en maîtrise des coûts.