Il y a quelque chose d’étrange avec Kubernetes : c’est probablement la technologie d’infrastructure la plus transformative de la dernière décennie, et pourtant chaque nouvelle version apporte son lot de « enfin ! », des fonctionnalités attendues depuis des années qui passent enfin en statut stable après des cycles de beta interminables. 2026 ne fait pas exception, et cette fois les nouveautés méritent vraiment l’attention de quiconque opère des clusters en production.

Trois évolutions majeures dominent l’actualité Kubernetes de ce premier semestre 2026 : l’In-Place Pod Resizing qui atteint le statut Generally Available (GA), les Sidecar Containers qui quittent la beta pour entrer en production officielle, et la Dynamic Resource Allocation (DRA) qui avance vers la beta avec des paramètres structurés. Chacune résout un problème opérationnel concret. Décortiquons-les.

In-Place Pod Resizing : la fin du restart-on-resize

C’est peut-être la fonctionnalité la plus attendue de l’histoire récente de Kubernetes pour les opérateurs en production. Jusqu’à présent, modifier les ressources CPU ou mémoire allouées à un pod, même d’un seul millicœur, nécessitait de tuer le pod et d’en créer un nouveau. Sur des applications stateful, des bases de données, des services avec des coûts de démarrage élevés, cette contrainte était une source de douleur opérationnelle constante.

L’In-Place Pod Resizing permet désormais de modifier les requests et limits de ressources d’un pod sans redémarrage. Le kubelet négocie avec le container runtime (containerd, CRI-O) pour ajuster les cgroups correspondants en temps réel. Pour un pod de base de données, passer de 4 à 8 vCPU en quelques secondes sans interruption de service, c’est une transformation fondamentale des capacités de scaling vertical.

La fonctionnalité est particulièrement précieuse en combinaison avec les Vertical Pod Autoscalers (VPA) qui peuvent désormais ajuster les ressources dynamiquement sans provoquer de churns de pods, un problème qui rendait VPA pratiquement inutilisable en production pour beaucoup d’équipes.

Sidecar Containers GA : un lifecycle enfin prévisible

Le pattern sidecar, un container auxiliaire qui tourne aux côtés du container principal dans le même pod, est l’un des patterns les plus utilisés dans l’écosystème Kubernetes : collecte de logs (Fluentd, Vector), injection de trafic (Envoy, Linkerd proxy), synchronisation de configurations, agentes de monitoring. Jusqu’en 2025, ces containers auxiliaires étaient des init containers avec un hack : ils ne terminaient jamais pour rester actifs.

Le problème ? Le lifecycle était imprévisible. Un sidecar qui redémarrait pouvait empêcher le pod d’atteindre l’état Running. L’ordre d’arrêt à la terminaison du pod était mal défini, causant des races conditions où le sidecar de collecte de logs s’arrêtait avant d’avoir flushé les derniers logs du container principal. Les probes de santé ne s’appliquaient pas correctement aux init containers en mode sidecar.

Avec les Sidecar Containers en GA, Kubernetes fournit un type de container dédié avec des garanties explicites : démarrage avant le container principal, arrêt après le container principal, probes de santé standards, gestion du lifecycle intégrée au scheduler. C’est une simplification architecturale majeure pour les service meshes et les stacks d’observabilité.

Dynamic Resource Allocation (DRA) : le GPU et au-delà

La DRA répond à un problème spécifique mais critique pour les workloads IA/ML et HPC : comment allouer efficacement des ressources hétérogènes, GPU, FPGA, SmartNIC, accélérateurs spécialisés, entre des pods Kubernetes, avec la même flexibilité et la même granularité que pour CPU et mémoire ?

Le modèle historique via les extended resources (nvidia.com/gpu: 1) était grossier : on demandait un nombre entier de devices, sans possibilité de partager ou de spécifier des attributs fins (type de GPU, mémoire VRAM disponible, topologie NUMA). La DRA avec paramètres structurés, désormais en beta, permet aux device plugins de publier des informations détaillées sur leurs ressources, et aux utilisateurs de les demander avec des critères précis.

# Exemple DRA : demander un GPU avec attributs spécifiques
apiVersion: resource.k8s.io/v1alpha3
kind: ResourceClaim
metadata:
  name: gpu-claim
spec:
  devices:
    requests:
    - name: gpu
      deviceClassName: gpu.nvidia.com
      selectors:
      - cel:
          expression: device.attributes["gpu.nvidia.com"].memory >= 24000  # 24 Go VRAM min
      - cel:
          expression: device.attributes["gpu.nvidia.com"].model in ["A100", "H100", "H200"]
---
apiVersion: v1
kind: Pod
metadata:
  name: training-job
spec:
  resourceClaims:
  - name: gpu
    resourceClaimName: gpu-claim
  containers:
  - name: trainer
    image: pytorch/pytorch:2.6
    resources:
      claims:
      - name: gpu

L’ère post-YAML : Pulumi, CDK8s et la programmabilité des clusters

Au-delà de ces fonctionnalités spécifiques, 2026 marque un tournant dans la façon dont les équipes définissent leur infrastructure Kubernetes. Le constat est simple : YAML ne passe pas à l’échelle. Gérer des centaines de manifestes, maintenir la cohérence entre environnements, tester les changements avant déploiement, tout cela devient un cauchemar de gestion de configuration au-delà d’un certain seuil de complexité.

Des outils comme Pulumi (TypeScript, Python, Go), CDK8s (AWS) et cdk8s+ permettent de définir des ressources Kubernetes dans de vrais langages de programmation, avec des boucles, des conditions, des fonctions, des tests unitaires, et l’écosystème complet des gestionnaires de paquets. Cette programmabilité transforme l’Infrastructure as Code en Infrastructure as Software, avec tout ce que cela implique en termes de pratiques de génie logiciel applicables à l’infra.

AI-Assisted Operations : les outils qui reécrivent les runbooks

En 2026, Kubernetes est devenu « the operating system for AI », mais l’IA s’invite aussi dans l’opération de Kubernetes lui-même. Des outils comme K8sGPT, Robusta, et les fonctionnalités d’AIOps intégrées dans les distributions cloud (GKE, EKS, AKS) analysent les événements, les logs et les métriques en temps réel pour suggérer des actions correctives, détecter les anomalies et expliquer les crashs en langage naturel.

Cette tendance est à double tranchant : elle démocratise la compréhension de Kubernetes pour des équipes moins expérimentées, mais crée aussi un risque de dépendance à des diagnostics automatiques qui peuvent être erronés dans des configurations non standards. L’IA assiste, elle ne remplace pas la compréhension profonde du système.

Platform Engineering : le contexte dans lequel tout cela s’inscrit

Ces évolutions techniques de Kubernetes ne se produisent pas en isolation. Elles s’inscrivent dans un mouvement plus large de Platform Engineering : la création de plateformes internes (Internal Developer Platforms, IDPs) qui abstraient la complexité de Kubernetes pour les équipes applicatives, tout en préservant la puissance et la flexibilité pour les équipes plateforme.

L’In-Place Pod Resizing, les Sidecars GA et la DRA sont précisément les types de primitives sur lesquelles les platform teams construisent des expériences développeur cohérentes, le scaling vertical automatique sans interruption, la collecte de logs standardisée, l’accès aux accélérateurs pour les équipes ML, sans que chaque développeur ait besoin de comprendre les détails d’implémentation Kubernetes sous-jacents.

Ce que vous devriez faire cette semaine

Si vous gérez des clusters Kubernetes en production, voici les actions concrètes à prioriser :

  • Auditer vos VPA deployments : l’In-Place Pod Resizing GA change significativement leur comportement et leur viabilité
  • Migrer vos init containers en mode sidecar vers le nouveau type natif pour bénéficier des garanties de lifecycle
  • Évaluer DRA si vous avez des workloads GPU : la beta est suffisamment mature pour des tests en staging
  • Documenter les dépendances YAML complexes : c’est le moment de rationaliser avant d’adopter Pulumi ou CDK8s

Kubernetes 2026 n’est pas une révolution conceptuelle, c’est la maturité opérationnelle qui arrive. Et c’est souvent là que réside la vraie valeur.

Right-sizing automatique : coupler VPA et redimensionnement à chaud

Le redimensionnement de pod sans redémarrage prend tout son sens quand on l’associe à l’ajustement vertical automatique. Jusqu’ici, le Vertical Pod Autoscaler devait expulser et recréer un pod pour modifier ses ressources, ce qui dissuadait de l’utiliser en production. Avec le redimensionnement à chaud devenu stable, le VPA peut ajuster CPU et mémoire à la volée, sans interruption, en suivant la charge réelle. On passe d’un dimensionnement statique et conservateur à un ajustement continu.

L’enjeu est double : fiabilité et coût. Un pod sur-provisionné gaspille des ressources facturées, un pod sous-provisionné risque l’éviction sous charge. Le right-sizing automatique élimine ce compromis. Cette mécanique s’intègre naturellement dans une démarche de standardisation des opérations, telle que la promeut le Platform Engineering et ses chemins pavés, où l’optimisation des ressources devient un réglage par défaut plutôt qu’un arbitrage manuel.

# VPA en mode "Auto" exploitant le resize à chaud (sans restart)
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata: { name: api-vpa }
spec:
  targetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
  updatePolicy:
    updateMode: "Auto"          # ajuste les ressources en continu
  resourcePolicy:
    containerPolicies:
      - containerName: api
        minAllowed: { cpu: 100m, memory: 128Mi }
        maxAllowed: { cpu: "2",  memory: 2Gi }

Migrer ses charges vers le lifecycle prévisible des sidecars

La stabilisation des conteneurs sidecar corrige un défaut historique de Kubernetes : l’ordre de démarrage et d’arrêt entre un conteneur principal et ses compagnons (proxy de service mesh, agent de logs) n’était pas garanti. Résultat, des applications démarraient avant leur proxy réseau et échouaient, ou se terminaient en laissant des logs orphelins. Le nouveau cycle de vie garantit que le sidecar démarre avant et s’arrête après le conteneur principal, comme on l’attend intuitivement.

Migrer ses charges existantes vers ce modèle élimine une catégorie entière de bugs de démarrage difficiles à diagnostiquer. C’est particulièrement décisif pour les architectures à maillage de services et les déploiements progressifs, comme ceux décrits dans notre guide blue-green avec Istio, où la fiabilité du proxy conditionne le basculement de trafic sans coupure.

# Sidecar au lifecycle garanti : démarre AVANT, s'arrête APRÈS l'app
spec:
  initContainers:
    - name: proxy-mesh
      image: registry.local/istio-proxy:hardened
      restartPolicy: Always       # <- en fait un vrai sidecar managé
  containers:
    - name: api
      image: registry.local/api:1.8
      # garanti que "proxy-mesh" est prêt avant le démarrage de "api"

Sécuriser DRA : partager des GPU sans ouvrir une brèche multi-tenant

L’allocation dynamique de ressources ouvre Kubernetes aux accélérateurs matériels, GPU, cartes spécialisées, mais introduit un risque de sécurité souvent négligé : plusieurs charges partageant un même GPU peuvent, sans cloisonnement, accéder à des données résiduelles en mémoire ou monopoliser le matériel. En contexte multi-tenant, l’isolation devient critique. Il faut définir des classes de ressources avec des frontières strictes et vérifier que le pilote nettoie la mémoire entre deux affectations.

Cette préoccupation rejoint l’hygiène générale des conteneurs : un accès matériel privilégié exige une base d’exécution durcie. Imposer des images de conteneurs durcies et des politiques d’admission strictes empêche qu’un pod abusant du GPU ne devienne un point de pivot. L’efficacité de DRA ne vaut que si elle s’accompagne de ce cloisonnement, sous peine de transformer un gain de performance en surface d’attaque.

# DRA : revendiquer un GPU via une classe de ressources cloisonnée
apiVersion: resource.k8s.io/v1
kind: ResourceClaim
metadata: { name: gpu-isole }
spec:
  devices:
    requests:
      - name: gpu
        deviceClassName: nvidia-gpu-mem-cleared   # mémoire purgée entre tenants
---
# Politique d'admission : refuser tout pod GPU non durci
# (runAsNonRoot, image signée, pas de privileged) -> via OPA/Gatekeeper

FinOps Kubernetes : transformer le redimensionnement en économies mesurables

Les nouveautés 2026 ne sont pas que techniques : elles ont un impact direct sur la facture cloud, à condition de les piloter. Le gaspillage le plus courant d’un cluster est l’écart entre les ressources demandées et les ressources réellement consommées, des pods qui réservent quatre fois ce qu’ils utilisent. Le redimensionnement à chaud combiné à une mesure continue permet de récupérer cet écart sans risque d’interruption, ce qui se traduit en économies concrètes et mesurables.

La démarche FinOps consiste à rendre ce gaspillage visible, puis à le réduire en boucle. Comparer périodiquement les demandes aux consommations réelles identifie les cibles de redimensionnement prioritaires. Cette gouvernance des coûts s’inscrit dans la continuité du provisionnement maîtrisé décrit dans notre guide Terraform pour EKS : on ne réduit durablement la facture que ce que l’on mesure d’abord précisément.

# Identifier le gaspillage : ratio demandé / réellement utilisé par pod
kubectl get pods -A -o json | jq -r '
  .items[] | .metadata.namespace + "/" + .metadata.name' 
  | while read pod; do
      kubectl top pod ${pod##*/} -n ${pod%%/*} --no-headers 2>/dev/null
    done | sort -k3 -h
# -> les pods dont l'usage est très inférieur aux requests = cibles de resize

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.

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.

GitOps et resize en place : éviter que le drift ne défasse l’ajustement

Un piège guette les équipes GitOps : redimensionner un pod à la main crée un écart entre l’état réel du cluster et la définition versionnée. À la prochaine synchronisation, l’outil de réconciliation peut écraser l’ajustement. La bonne pratique est de traiter le resize comme tout changement d’infrastructure : il passe par le dépôt Git, pas par une commande impérative oubliée le lendemain.

Cette discipline de réconciliation est au cœur du GitOps, que nous explorons dans notre tutoriel ArgoCD pour Kubernetes. Le resize en place n’est utile durablement que s’il est gouverné, pas bricolé.

# La ressource cible vit dans Git : ArgoCD la reconcilie, pas un kubectl manuel
resources:
  requests: { cpu: "500m", memory: "512Mi" }   # ajuste via PR, pas a la main
  limits:   { cpu: "1",    memory: "1Gi" }
# resizePolicy permet le changement sans redemarrage du conteneur
resizePolicy:
  - resourceName: memory
    restartPolicy: NotRequired

Sources

WP Admin Lab
· Chef de la rédaction

La rédaction de WP Admin Lab réunit des praticiens WordPress, sécurité et développement web. Nous publions des guides testés en conditions réelles, vérifiés en production et régulièrement mis à jour, sans jargon inutile. Chaque procédure est relue avant publication.

mastodon