Kubernetes 1.29 : Sidecar Containers GA et JobSet pour ML

La Cloud Native Computing Foundation (CNCF) a publié le 23 octobre 2025 Kubernetes 1.29, une version majeure qui finalise les Sidecar Containers, introduit JobSet pour les workloads ML/AI et renforce considérablement la sécurité avec Pod Security Admission GA.

Sidecar Containers : Enfin Stables

De Beta à General Availability

Les Sidecar Containers, attendus depuis 2019, sont maintenant production-ready :

Architecture traditionnelle (problématique) :

apiVersion: v1
kind: Pod
metadata:
  name: app-with-proxy
spec:
  containers:
  - name: app
    image: myapp:1.0
  - name: envoy-proxy  # Init avant app? Après? Ordre aléatoire!
    image: envoyproxy/envoy:v1.28

Problèmes :

• Ordre de démarrage non garanti
• Shutdown race conditions
• Impossibilité d'attendre qu'un sidecar soit ready

Nouvelle architecture (K8s 1.29) :

apiVersion: v1
kind: Pod
metadata:
  name: app-with-proxy
spec:
  initContainers:
  - name: envoy-proxy
    image: envoyproxy/envoy:v1.28
    restartPolicy: Always  # Nouveau ! Marque comme sidecar
    # Démarre AVANT app et reste actif

  containers:
  - name: app
    image: myapp:1.0
    # Démarre uniquement quand envoy est ready

Avantages :

• Ordre garanti : sidecars démarrent avant containers principaux
• Lifecycle géré : sidecars s'arrêtent après les containers principaux
• Health checks : app attend que sidecars soient ready
• Backwards compatible : pas de breaking change

Use Cases Réels

Service Mesh (Istio, Linkerd) :

spec:
  initContainers:
  - name: istio-proxy
    image: istio/proxyv2:1.20
    restartPolicy: Always
    # Configure iptables puis reste actif comme proxy

  containers:
  - name: backend
    image: backend:v2
    # Traffic déjà intercepté par Istio au démarrage

Logging/Monitoring :

spec:
  initContainers:
  - name: fluent-bit
    image: fluent/fluent-bit:2.2
    restartPolicy: Always
    volumeMounts:
    - name: logs
      mountPath: /var/log

  containers:
  - name: app
    image: app:latest
    # Logs collectés dès le premier log

JobSet : ML/AI Workloads Natifs

Nouvelle API pour Distributed Training

Problème ancien : Entraîner un modèle ML distribué nécessitait des scripts custom complexes pour gérer :

• Coordination de N workers
• Parameter servers
• Elastic scaling

Solution : JobSet (nouveau CRD)

apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: pytorch-training
spec:
  # Groupe de workers
  replicatedJobs:
  - name: workers
    replicas: 8  # 8 workers PyTorch
    template:
      spec:
        parallelism: 8
        completions: 8
        template:
          spec:
            containers:
            - name: pytorch
              image: pytorch/pytorch:2.1
              command: ["torchrun"]
              args:
                - "--nnodes=8"
                - "--nproc_per_node=4"
                - "train.py"
              resources:
                limits:
                  nvidia.com/gpu: 4

  # Parameter server
  - name: ps
    replicas: 2
    template:
      spec:
        template:
          spec:
            containers:
            - name: tensorflow-ps
              image: tensorflow/tensorflow:2.14-gpu

  # Politique de succès
  successPolicy:
    operator: All  # Tous les jobs doivent réussir

Features :

• Coordination automatique : variables d'environnement injectées (rank, world size, etc.)
• Elastic scaling : ajout/suppression de workers dynamique
• Fault tolerance : restart automatique des workers failed
• DNS interne : workers se découvrent automatiquement

Performance

Benchmark : Entraînement GPT-3 (175B paramètres)

JobSet = plus simple, plus rapide, moins cher !

Pod Security Admission : GA

Remplacement de PodSecurityPolicy

Ancien système (déprécié) :

• PodSecurityPolicy : complexe, confus
• Supprimé dans K8s 1.25

Nouveau système (stable en 1.29) :

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    # 3 niveaux : privileged, baseline, restricted
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

3 Niveaux de Sécurité :

1. Privileged (permissif) ** :

• Aucune restriction
• Pour system workloads (CNI, CSI, etc.)

2. Baseline (recommandé pour la plupart) ** :

• Interdit les privilèges dangereux
• Autorise les use cases communs

# ❌ Bloqué en baseline
spec:
  containers:
  - name: app
    securityContext:
      privileged: true  # Interdit

# ✅ Autorisé en baseline
spec:
  containers:
  - name: app
    securityContext:
      runAsNonRoot: true
      capabilities:
        drop: ["ALL"]

3. Restricted (maximum security) ** :

• Restrictions strictes
• Best practices appliquées

# Baseline + restrictions additionnelles
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true

Migration Guidée

Étape 1 : Audit mode

metadata:
  labels:
    pod-security.kubernetes.io/audit: restricted
    # Log les violations sans bloquer

Étape 2 : Warning mode

metadata:
  labels:
    pod-security.kubernetes.io/warn: restricted
    # Affiche warnings dans kubectl

Étape 3 : Enforce

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted
    # Bloque les Pods non-conformes

Amélioration Performances

Optimisations Scheduling

Scheduler 30% plus rapide :

Optimisations :

• Cache de scheduling amélioré
• Parallélisation accrue
• Pre-filtering des nodes

API Server : ReadWriteMany Volumes

Support amélioré des volumes partagés :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-data
spec:
  accessModes:
  - ReadWriteMany  # Plusieurs Pods peuvent écrire
  resources:
    requests:
      storage: 100Gi
  storageClassName: nfs-dynamic

Providers supportés :

• NFS, CephFS, GlusterFS
• Azure Files, AWS EFS
• Google Filestore

Use case : Workloads collaboratifs (Jupyter notebooks partagés, data processing)

ValidatingAdmissionPolicy : GA

Policy-as-Code sans Webhooks

Anciennes solutions :

• OPA/Gatekeeper : lourd, nécessite webhook externe
• Kyverno : CRDs additionnels

Nouveau : ValidatingAdmissionPolicy (natif K8s)

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-labels
spec:
  # CEL (Common Expression Language)
  validations:
  - expression: "has(object.metadata.labels.team)"
    message: "All resources must have a 'team' label"

  - expression: "has(object.metadata.labels.env)"
    message: "All resources must have an 'env' label"

  matchConstraints:
    resourceRules:
    - apiGroups: ["apps"]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["deployments"]

Binding à un namespace :

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: require-labels-prod
spec:
  policyName: require-labels
  matchResources:
    namespaceSelector:
      matchLabels:
        env: production

Avantages :

• Pas de webhook externe = latence réduite
• CEL langage standard (aussi dans Google Cloud, Envoy)
• Performance : 10x plus rapide qu'OPA

kubectl : UX Améliorée

Nouvelles Commandes

kubectl events (enfin!) :

# Avant : kubectl get events --sort-by=.metadata.creationTimestamp
# Maintenant :
kubectl events

# Filtrer par objet
kubectl events --for pod/myapp
kubectl events --for deployment/backend

# Watch mode
kubectl events --watch

kubectl debug : remote debugging amélioré

# Copier un Pod avec modifications
kubectl debug mypod --copy-to=debug-pod \
  --set-image=app=debug-image:latest \
  --env="LOG_LEVEL=debug"

# Attacher un conteneur ephemeral avec outils debug
kubectl debug mypod -it --image=nicolaka/netshoot
# Alpine avec curl, netstat, tcpdump, etc.

Écosystème

Intégrations Majeures

Helm 3.14 :

• Support natif des Sidecars
• Chart templates améliorés

ArgoCD 2.10 :

• JobSet support
• Sync wave pour sidecars

Prometheus 2.48 :

• Métriques JobSet
• Sidecar container tracking

Migration 1.28 → 1.29

Checklist

Breaking changes mineurs :

1. Removed APIs :

   • flowcontrol.apiserver.k8s.io/v1beta2 supprimée
   • Migration vers v1

2. Feature gates :

   • LegacyServiceAccountTokenNoAutoGeneration GA (plus de secrets auto-générés)

Procédure recommandée :

# 1. Backup etcd
kubectl get all --all-namespaces -o yaml > backup.yaml

# 2. Upgrade control plane
kubeadm upgrade apply v1.29.0

# 3. Upgrade nodes (rolling)
kubectl drain node1
# Upgrade kubelet/kubeproxy sur node1
kubectl uncordon node1

# 4. Vérification
kubectl get nodes  # Tous en v1.29
kubectl get pods -A  # Tous running

Futur : Kubernetes 1.30 Preview

Roadmap annoncée (Q1 2026) :

• Dynamic Resource Allocation : GPU, FPGA partagés
• In-Place Pod Resize : changer CPU/RAM sans restart
• Structured Authentication : OIDC natif amélioré

Articles connexes

Pour approfondir le sujet, consultez également ces articles :

• Docker Desktop 5.0 : Extensions IA et Performance Révolutionnaire en 2025
• AWS Graviton 4 : Les Processeurs ARM Révolutionnent le Cloud Computing en 2025
• Docker Compose Watch Mode : Hot Reload pour Microservices

Conclusion

Kubernetes 1.29 apporte des améliorations fondamentales avec les Sidecars stables, JobSet pour ML/AI et une sécurité renforcée. Cette version confirme K8s comme plateforme d'orchestration incontournable pour tous types de workloads.

Pour les équipes DevOps :

• Simplification des architectures sidecar
• Sécurité renforcée avec Pod Security Admission
• Meilleures performances

Pour les équipes ML/AI :

• JobSet révolutionne le distributed training
• Plus simple que Kubeflow pour cas simples
• Elastic scaling natif

Recommandation : Migrer dès que possible pour bénéficier de la stabilité des Sidecars.

Kubernetes 1.29 = la version la plus robuste et complète à ce jour.