Si vous avez déjà lancé un entraînement ML distribué sur Kubernetes, vous connaissez le scénario : un job qui réclame 8 pods × 8 GPU. Le scheduler en place 5… puis tombe à court de ressources pour les 3 derniers. Résultat : 5 pods qui consomment des heures GPU sans rien faire, en attendant les 3 qui ne viendront jamais. C’est un deadlock de scheduling, et jusqu’ici la solution passait par des outils externes comme Volcano ou Kueue.

La 1.35 introduit le concept natif de PodGroup : on définit le groupe, on précise le nombre minimum de pods requis, et Kubernetes garantit un placement « all-or-nothing ». Tous les pods sont placés simultanément, ou aucun ne l’est. Plus de déploiements partiels, plus de ressources gaspillées.

Statut : alpha en 1.35 — feature gate à activer. À tester en non-prod si vous opérez de l’IA à l’échelle.

Six ans qu’on attendait ce KEP. Il est enfin stable et general availability. Concrètement : vous pouvez modifier les requests et limits CPU / mémoire d’un pod sans le redémarrer.

Exemple type : un pod d’inférence tourne avec 512 Mo de mémoire, il commence à saturer. Avant : on patch le Deployment, on déclenche un rollout, on redémarre. Maintenant :

kubectl patch pod mon-pod --subresource resize --patch '
spec:
  containers:
  - name: app
    resources:
      requests:
        memory: "1Gi"
      limits:
        memory: "1Gi"
'

Le conteneur continue de tourner, le kernel ajuste les cgroups à la volée. Pas de redémarrage, pas de connexions cassées, pas de cache vidé. Massif pour tout workload où le redémarrage coûte cher : services ML, batch, charges stateful. Bêta depuis la 1.33, GA aujourd’hui — safe pour la production.

Jusqu’ici, la restartPolicy est appliquée au pod entier : un sidecar GPU qui crashe entraîne le redémarrage de tout le pod, y compris le job d’entraînement principal qui tournait depuis 4 heures.

La 1.35 introduit des politiques par conteneur avec déclenchement basé sur le code de sortie. Pod avec trois conteneurs — job d’entraînement, sidecar driver GPU, conteneur de logs. Si le driver GPU se prend un OOMKill (exit code 137), seul ce conteneur redémarre — le training continue. Pour un exit code 1 (probable bug applicatif), on peut au contraire choisir de ne pas redémarrer pour conserver les logs.

Statut : bêta, activée par défaut en 1.35. Utilisable dès aujourd’hui.

Aujourd’hui, mettre en place du Zero Trust dans Kubernetes implique généralement cert-manager ou SPIRE pour l’émission des certificats, des CRD pour orchestrer les requêtes, des Secrets pour le stockage, et des sidecars / init containers pour la rotation. Ça marche, mais c’est beaucoup d’infrastructure.

La 1.35 fait passer ce mécanisme en natif :

• le kubelet génère les clés localement ;
• il crée une PodCertificateRequest ;
• l’API server émet le certificat directement ;
• le kubelet écrit le bundle d’identifiants dans le filesystem du pod ;
• rotation automatique, sans sidecar.

Bonus sécurité : l’API server applique les node restrictions dès l’admission, ce qui élimine l’un des pièges classiques des signers tiers. Flux mTLS pur, sans bearer token dans le chemin d’émission.

cert-manager et SPIRE ne disparaissent pas — ils couvrent des cas d’usage avancés que cette feature ne traite pas. Mais pour de l’identité workload basique et du service-to-service mTLS, le natif devient une option crédible.

Le scénario : vous lancez un Job de batch, six heures plus tard il tombe en OOMKill car la limite mémoire était trop basse. Avant la 1.35, il faut supprimer puis recréer le Job — vous perdez le statut, l’historique, le suivi de complétion.

Avec la 1.35, on peut désormais suspendre un Job, ajuster ses ressources, puis le reprendre :

# 1. Suspendre
kubectl patch job mon-job --type=merge -p '{"spec":{"suspend":true}}'

# 2. Modifier les ressources
kubectl patch job mon-job --type=merge -p '{"spec":{"template":{"spec":{"containers":[{"name":"worker","resources":{"limits":{"memory":"4Gi"}}}]}}}}'

# 3. Reprendre
kubectl patch job mon-job --type=merge -p '{"spec":{"suspend":false}}'

Même objet Job, exécution reprise, suivi de complétion intact. Énorme pour le batch et l’entraînement ML où l’on itère souvent sur les besoins en ressources. Statut : alpha — feature gate à activer.