Kubernetes 1.35 : le cloud native passe à l'ère de l'IA

Kubernetes 1.35 est disponible depuis le 17 décembre 2025. Cette version marque un tournant pour l'écosystème cloud native avec des fonctionnalités spécifiquement conçues pour les workloads d'intelligence artificielle et de machine learning. Gang Scheduling, Dynamic Resource Allocation amélioré, gestion intelligente des GPU : Kubernetes s'adapte aux exigences des infrastructures modernes.

L'adoption cloud native explose

Avant de plonger dans les nouveautés, un constat s'impose : le cloud native n'a jamais été aussi populaire.

15,6 millions de développeurs cloud native

Le rapport State of Cloud Native Development de la CNCF (novembre 2025) révèle des chiffres impressionnants :

L'adoption s'accélère également côté infrastructure :

• Hybrid cloud : 32% des développeurs (vs 22% en 2021)
• Multi-cloud : 26% des organisations
• CI/CD : 60% d'adoption (+31% en un an)
• GitOps : 77% d'adoption

Kubernetes en production

L'enquête CNCF Annual Survey 2024 confirme la maturité de l'écosystème :

• 80% des organisations utilisent Kubernetes en production
• 13% supplémentaires sont en phase pilote
• 52% exécutent la majorité de leurs applications en conteneurs

L'écosystème CNCF prospère avec Helm (75% d'adoption), etcd, CoreDNS, Cert Manager et Argo parmi les projets les plus utilisés. Argo CD atteint 97% d'utilisation en production.

Gang Scheduling : la révolution pour l'IA

La fonctionnalité la plus attendue de Kubernetes 1.35 est le Gang Scheduling natif, disponible en alpha.

Le problème historique

Kubernetes est massivement utilisé pour les jobs IA, ML et HPC nécessitant l'exécution simultanée de multiples processus. Le scheduler historique fonctionne Pod par Pod, allouant séquentiellement les ressources.

Le scénario catastrophe : votre job ML nécessite 10 workers avec GPU. Le cluster n'en accepte que 5. Ces 5 Pods sont schedulés, consomment des ressources GPU coûteuses... et attendent indéfiniment les 5 autres. Résultat :

• Ressources bloquées inutilement
• Deadlocks potentiels
• Coûts GPU qui explosent
• Jobs qui timeout

La solution : All-or-Nothing

Le Gang Scheduling implémente le principe "Tout ou rien". Un groupe de Pods (gang) n'est schedulé que si les ressources sont disponibles pour tous les membres du gang, ou pour un quorum minimum défini par le paramètre minCount.

La nouveauté technique : l'introduction d'un nouveau type core appelé Workload. Cet objet permet au scheduler de reconnaître les groupes de Pods qui doivent être schedulés ensemble pour que les applications parallèles puissent démarrer et progresser.

Impact pratique

Pour l'entraînement distribué (PyTorch DDP, Horovod, TensorFlow MultiWorker), cette fonctionnalité est transformatrice :

apiVersion: batch/v1
kind: Job
metadata:
  name: distributed-training
spec:
  parallelism: 8
  completions: 8
  podSchedulingPolicy:
    gangScheduling:
      minCount: 8  # Tous ou rien

Plus de workers orphelins, plus de ressources gaspillées, plus de deadlocks.

Dynamic Resource Allocation 2.0

La Dynamic Resource Allocation (DRA) permet la provision dynamique de ressources hardware spécialisées (GPU, TPU, FPGA) via une API standardisée. Kubernetes 1.35 apporte deux améliorations majeures.

Device Binding Conditions

La fonctionnalité Device Binding Conditions (KEP #5007) introduit un mécanisme de BindingConditions qui diffère le binding des Pods jusqu'à confirmation que les ressources externes sont prêtes.

Le cas d'usage : les GPU fabric-attached ou les FPGA ne sont pas instantanément disponibles. L'ancien scheduler supposait une disponibilité immédiate, causant des échecs. Avec cette amélioration, le binding n'intervient qu'après confirmation de la disponibilité effective.

Partitionable Devices

Partitionable Devices (KEP #4815) restaure la capacité de partitionner dynamiquement les devices (GPU multi-instances, devices logiques) dans le framework DRA moderne.

Les vendors peuvent annoncer des partitions overlapping créées à la demande après allocation. Concrètement, un GPU A100 peut être partitionné en MIG (Multi-Instance GPU) selon les besoins réels du workload.

Extended Toleration Operators

Une nouvelle proposition étend les Tolerations Kubernetes pour supporter les opérateurs de comparaison numérique (Lt, Gt) lors du matching avec les Node Taints.

Scheduling SLA-aware

Cette fonctionnalité permet un scheduling intelligent mixant :

• Nodes high-SLA (on-demand, garantis)
• Nodes low-SLA (spot, preemptible)

Avantages vs NodeAffinity :

• Policy orientation : les nodes déclarent leur niveau de risque, les pods opt-in
• Sémantiques d'éviction : NoExecute + tolerationSeconds pour un drain graceful quand le SLA du node se dégrade

Pour les workloads IA avec tolérance aux interruptions (checkpointing), c'est un game-changer pour optimiser les coûts.

Pod Batching pour le scale

Le Pod Batching passe en Beta (activé par défaut). Cette fonctionnalité réduit significativement le coût du scheduling dans les grands clusters ou pour les Jobs massifs.

Le concept de signature

Le scheduler peut réutiliser les décisions de scheduling pour d'autres Pods ayant la même signature. Cette signature résume ce dont le Pod a besoin pour être placé sur un node.

Impact : pour un Job de 1000 Pods identiques, le scheduler calcule une fois et applique mille fois. Les benchmarks montrent des gains de performance de 10x à 100x sur les jobs à grande échelle.

Autres nouveautés notables

Pod Level Vertical Scaling

Le scaling vertical au niveau Pod permet d'ajuster les ressources (CPU, mémoire) d'un Pod sans le recréer. Essential pour les workloads IA dont les besoins varient selon la phase (inférence vs fine-tuning).

Mutable PersistentVolume Node Affinity

Les PV peuvent désormais changer d'affinité de node. Utile pour la migration de workloads stateful ou le rebalancing de stockage.

Container Restart Actions

De nouvelles actions de restart conteneur offrent un contrôle plus fin sur le comportement en cas d'échec, crucial pour les pipelines ML complexes.

Kubernetes et l'IA : la roadmap

Au-delà de 1.35, Kubernetes continue d'évoluer pour mieux servir les workloads IA. Les axes de développement incluent :

Intégration native des accélérateurs

• Support amélioré des GPU NVIDIA, AMD, Intel
• TPU Google Cloud natif
• Accélérateurs custom via DRA

Orchestration ML

• Intégration avec Kubeflow
• Support MLflow amélioré
• Pipelines de training distribué

Optimisation des coûts

• Scheduling spot-aware
• Autoscaling prédictif
• Bin-packing intelligent pour GPU

Migrer vers 1.35 : les considérations

Prérequis

• Kubernetes 1.33 minimum recommandé
• Feature gates à activer pour les fonctionnalités alpha
• Tests sur environnement de staging

Fonctionnalités stables à exploiter

Fonctionnalités alpha à tester

L'écosystème CNCF en 2025

Kubernetes 1.35 s'inscrit dans un écosystème cloud native mature :

Les projets graduated les plus utilisés

1. Kubernetes - Orchestration
2. Prometheus - Monitoring
3. Envoy - Service mesh data plane
4. CoreDNS - DNS
5. containerd - Container runtime
6. Helm - Package manager
7. Argo - GitOps & workflows

Les tendances émergentes

• eBPF pour l'observabilité et la sécurité réseau
• WebAssembly comme runtime alternatif aux conteneurs
• Backstage pour les portails développeurs
• Crossplane pour l'infrastructure as code Kubernetes-native

Conclusion

Kubernetes 1.35 représente une évolution majeure pour les workloads d'intelligence artificielle. Le Gang Scheduling natif élimine une des plus grandes frustrations des équipes ML, tandis que les améliorations DRA facilitent la gestion des accélérateurs hardware.

Avec 15,6 millions de développeurs cloud native et 80% d'adoption en production, Kubernetes est devenu l'infrastructure de facto pour le déploiement d'applications. Cette version confirme que la CNCF et la communauté Kubernetes ont compris les enjeux de l'ère IA.

La mise à niveau vers 1.35 mérite d'être planifiée dès maintenant, particulièrement pour les organisations qui investissent dans le ML. Les fonctionnalités alpha d'aujourd'hui deviendront les standards de demain.