Kubernetes (K8s)

Kubernetes (abrégé K8s) est une plateforme open source d’orchestration de conteneurs qui automatise le déploiement, le scaling, le networking et la gestion d’applications conteneurisées à grande échelle.

Si Docker crée et exécute des conteneurs individuels, Kubernetes gère des clusters entiers de conteneurs en production. Il décide où placer chaque conteneur, combien de réplicas maintenir, comment distribuer le trafic, et comment réagir quand un conteneur tombe en panne. C’est le système d’exploitation de l’infrastructure cloud-native, et en 2026, il est devenu le socle standard pour déployer des modèles ML et des applications IA en production.

Catégorie: Orchestration de conteneurs
Créateur: Google (open-sourcé en 2014), maintenu par la CNCF
Licence: Apache 2.0
Version stable: 1.35.2 (février 2026), v1.36 prévu pour avril 2026
Cycle de release: ~15 semaines, support N-2 (14 mois par version)
Communauté: 88 000+ contributeurs, 8 000+ organisations, 44 pays
URL: kubernetes.io

Pourquoi Kubernetes existe

Quand vous avez un conteneur sur un serveur, la gestion est simple. Quand vous avez des centaines de conteneurs sur des dizaines de serveurs, les questions se multiplient : sur quel serveur lancer ce conteneur ? Que faire si un serveur tombe ? Comment distribuer le trafic ? Comment gérer les mises à jour sans downtime ? Comment partager les GPU entre les workloads ML ?

Kubernetes résout ces problèmes en fournissant une couche d’abstraction déclarative : vous décrivez l’état désiré (« je veux 3 réplicas de ce modèle, avec accès GPU, exposés sur ce port ») et Kubernetes s’assure en continu que cet état est maintenu, automatiquement. C’est la différence entre gérer l’infrastructure à la main et avoir un système autonome qui s’auto-corrige.

Kubernetes est né chez Google, inspiré par le système interne Borg qui gérait les workloads de production de Google depuis plus d’une décennie. Open-sourcé en 2014, il est devenu un projet de la CNCF (Cloud Native Computing Foundation) et le standard de facto pour l’orchestration de conteneurs, adopté par tous les cloud providers majeurs (AWS EKS, GCP GKE, Azure AKS).

Architecture de Kubernetes

Un cluster Kubernetes se compose d’un control plane (le cerveau) et de nodes workers (les muscles).

Control plane

Le control plane prend toutes les décisions de scheduling et gère l’état du cluster. Ses composants principaux :

kube-apiserver : le point d’entrée unique pour toutes les interactions avec le cluster. Toutes les commandes kubectl, toutes les requêtes des composants internes passent par l’API server. Il valide les requêtes et persiste l’état dans etcd.

etcd : le datastore distribué qui stocke l’état complet du cluster (configurations, secrets, état des pods). C’est la source de vérité. Si etcd est perdu sans backup, le cluster est perdu.

kube-scheduler : décide sur quel node placer chaque nouveau pod. Il prend en compte les ressources disponibles (CPU, mémoire, GPU), les contraintes d’affinité/anti-affinité, les taints/tolerations, et les quality-of-service.

kube-controller-manager : exécute les boucles de contrôle qui surveillent l’état du cluster et agissent pour converger vers l’état désiré. Par exemple, le ReplicaSet controller s’assure que le bon nombre de réplicas tourne en permanence.

Nodes workers

Les nodes sont les machines (physiques ou virtuelles) qui exécutent les conteneurs. Chaque node contient :

kubelet : l’agent qui tourne sur chaque node, reçoit les instructions du control plane, et s’assure que les conteneurs des pods sont en cours d’exécution et en bonne santé.

Container runtime : le logiciel qui exécute les conteneurs (containerd, CRI-O). Note : Docker n’est plus utilisé directement comme runtime Kubernetes depuis la version 1.24, remplacé par containerd.

kube-proxy : gère les règles réseau sur chaque node pour permettre la communication entre les pods et l’exposition des services.

Les concepts fondamentaux

Pod

Le pod est la plus petite unité déployable dans Kubernetes. Un pod contient un ou plusieurs conteneurs qui partagent le même réseau et le même stockage. En pratique, la plupart des pods contiennent un seul conteneur (votre application ou votre modèle ML). Les pods sont éphémères : ils peuvent être créés, détruits et recréés à tout moment par Kubernetes.

Deployment

Un Deployment décrit l’état désiré pour vos pods : quelle image de conteneur, combien de réplicas, quelles ressources. Kubernetes crée et maintient les pods correspondants. Si un pod tombe, le Deployment en recrée un automatiquement. Les mises à jour se font par rolling update (remplacement progressif des pods) pour éviter le downtime.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-model-api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ml-model
  template:
    metadata:
      labels:
        app: ml-model
    spec:
      containers:
      - name: model-server
        image: mon-registre/model-server:v2.1
        ports:
        - containerPort: 8000
        resources:
          requests:
            cpu: "1"
            memory: "2Gi"
          limits:
            cpu: "2"
            memory: "4Gi"
        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 30

Service

Un Service expose un ensemble de pods derrière une adresse réseau stable. Les pods sont éphémères (leurs IP changent), mais le Service fournit un DNS fixe et un load balancing entre les pods. Types principaux : ClusterIP (interne au cluster), NodePort (expose sur un port de chaque node), LoadBalancer (provisionne un load balancer cloud).

Namespace

Les namespaces isolent logiquement les ressources au sein d’un cluster. Utilisez-les pour séparer les environnements (dev, staging, production), les équipes, ou les projets. Les quotas de ressources et les politiques réseau s’appliquent par namespace.

Horizontal Pod Autoscaler (HPA)

Le HPA ajuste automatiquement le nombre de réplicas d’un Deployment en fonction de métriques observées (utilisation CPU, mémoire, métriques custom). Exemple typique : maintenir l’utilisation CPU à 70%, avec un minimum de 2 et un maximum de 20 réplicas.

Volumes et stockage persistant

Les pods sont éphémères, mais les données doivent souvent persister. Les PersistentVolumes (PV) et PersistentVolumeClaims (PVC) fournissent du stockage durable, découplé du cycle de vie des pods. Essentiel pour les bases de données, les logs, et le stockage de modèles ML.

Kubernetes pour l’IA et le ML

Kubernetes est devenu le socle d’infrastructure dominant pour le MLOps et les applications IA en production. Voici pourquoi et comment.

Scheduling GPU

Kubernetes, via le NVIDIA GPU Operator et les device plugins, gère nativement l’allocation de GPU aux pods. Vous demandez un GPU dans votre manifest YAML (nvidia.com/gpu: 1) et le scheduler place le pod sur un node qui en dispose. Le GPU est isolé : aucun autre pod ne peut y accéder tant qu’il est alloué.

Pour optimiser l’utilisation GPU, des techniques avancées existent : MIG (Multi-Instance GPU) partitionne un GPU physique en slices isolés, et le time-slicing partage un GPU entre plusieurs pods. Le choix dépend de vos besoins d’isolation vs. d’utilisation.

KServe : model serving natif

KServe est le framework de model serving natif pour Kubernetes. Il fournit un CRD InferenceService qui standardise le déploiement de modèles avec auto-scaling (y compris scale-to-zero), canary rollouts, et support multi-runtime (vLLM, Triton, TorchServe, Hugging Face). KServe v0.15 a ajouté le support natif vLLM avec distributed KV cache.

Kubeflow : pipelines ML

Kubeflow est la plateforme open source qui étend Kubernetes pour les workflows ML complets. Kubeflow Pipelines orchestre les étapes du pipeline (ingestion, entraînement, évaluation, déploiement) comme des pods Kubernetes. Kubeflow 1.11 (dernière version stable) inclut KFP 2.15, KServe 0.15.2, un Model Registry, et le support de Kubernetes 1.31-1.33+.

Ray on Kubernetes

Ray est un framework de calcul distribué qui s’exécute nativement sur Kubernetes via le KubeRay operator. Ray Serve est une alternative à KServe pour le model serving distribué, particulièrement adapté aux workloads qui nécessitent du calcul parallèle (entraînement distribué, hyperparameter tuning, inférence multi-modèle).

Entraînement distribué

Kubernetes gère l’entraînement distribué de modèles ML sur des clusters de GPU. Le Kubeflow Training Operator orchestre les jobs d’entraînement PyTorch, TensorFlow et JAX distribués. Chaque worker d’entraînement est un pod avec un ou plusieurs GPU, et Kubernetes gère le placement, le networking et la tolérance aux pannes.

Services Kubernetes managés

Gérer un cluster Kubernetes soi-même (le control plane, les mises à jour, etcd, la sécurité) est complexe. Les cloud providers proposent des services managés qui s’occupent du control plane :

Service	Cloud	Particularités
EKS	AWS	Intégration IAM, Fargate (serverless pods), EKS Anywhere (on-prem)
GKE	GCP	Autopilot (nodes managés), GKE Enterprise, Managed OpenTelemetry, TPU natif
AKS	Azure	Intégration Azure AD, Azure Arc (multi-cloud), KEDA natif

Pour des environnements plus légers ou edge, des distributions alternatives existent : K3s (Rancher, ultra-léger, adapté à l’edge et à l’IoT), K0s (Mirantis), et MicroK8s (Canonical).

kubectl : l’outil en ligne de commande

kubectl est la CLI principale pour interagir avec un cluster Kubernetes. Toutes les opérations passent par l’API server. Voici les commandes essentielles pour le quotidien :

# Voir les pods en cours d'exécution
kubectl get pods -n mon-namespace

# Voir les logs d'un pod (utile pour debugger un modèle ML)
kubectl logs mon-model-pod -f

# Déployer un manifest
kubectl apply -f deployment.yaml

# Voir l'utilisation des ressources (CPU, mémoire, GPU)
kubectl top pods -n ml-serving

# Exécuter une commande dans un pod (debug)
kubectl exec -it mon-pod -- bash

# Voir les événements du cluster (diagnostiquer les problèmes de scheduling)
kubectl get events --sort-by='.lastTimestamp'

# Rollback un deployment à la version précédente
kubectl rollout undo deployment/ml-model-api

Pour les environnements de développement local, des outils comme Minikube, Kind (Kubernetes IN Docker) et K3d permettent de lancer un cluster Kubernetes complet sur votre machine en quelques minutes. C’est indispensable pour tester vos manifests avant de les déployer en production.

Bonnes pratiques Kubernetes

Définissez toujours des requests et limits. Les resource requests (minimum garanti) et limits (maximum autorisé) pour CPU et mémoire sont essentiels. Sans requests, le scheduler ne peut pas placer les pods correctement. Sans limits, un pod peut consommer toutes les ressources du node et crasher les autres pods.

Configurez des health checks. Les readiness probes indiquent quand un pod est prêt à recevoir du trafic (essentiel pour les modèles ML qui prennent du temps à charger). Les liveness probes détectent les pods bloqués et les redémarrent automatiquement.

Utilisez des namespaces pour l’isolation. Séparez les environnements (dev/staging/prod), appliquez des ResourceQuotas par namespace pour éviter qu’une équipe ne monopolise les ressources, et utilisez des NetworkPolicies pour contrôler le trafic entre namespaces.

Automatisez les mises à jour. Kubernetes suit un cycle de release de 15 semaines avec un support N-2 (14 mois par version mineure). Mettez à jour régulièrement pour bénéficier des patches de sécurité. Les cloud providers managés facilitent les upgrades du control plane.

Sécurisez avec PodSecurityStandards. Depuis Kubernetes 1.25, les PodSecurityPolicies sont supprimées. Utilisez les PodSecurityStandards (Privileged, Baseline, Restricted) via le PodSecurity admission controller pour limiter les permissions des pods.

etcd est votre point critique etcd stocke tout l’état du cluster. Sauvegardez-le régulièrement. Un etcd corrompu ou perdu sans backup signifie la perte complète du cluster. Les services managés (EKS, GKE, AKS) gèrent cela pour vous, ce qui est un argument fort en leur faveur.

Quand utiliser (ou ne pas utiliser) Kubernetes

Utilisez Kubernetes si : vous avez plusieurs services/modèles à orchestrer, vous avez besoin d’auto-scaling (surtout GPU), vous voulez des déploiements sans downtime (rolling updates, canary), vous avez une équipe capable de l’opérer, ou vous utilisez un service managé (EKS, GKE, AKS).

N’utilisez pas Kubernetes si : vous déployez un seul service simple (un docker run sur un serveur suffit), votre équipe est petite et sans expertise DevOps, ou votre budget ne justifie pas la complexité opérationnelle. Dans ces cas, un simple Docker Compose, un PaaS (Railway, Render, Fly.io) ou du serverless (Lambda, Cloud Functions) sera plus productif.

Le test décisif Si vous passez plus de temps à gérer Kubernetes qu’à améliorer vos modèles ou votre produit, vous avez probablement introduit Kubernetes trop tôt. Commencez simple, ajoutez Kubernetes quand la complexité de votre infrastructure le justifie.

Erreurs courantes

Pas de resource requests/limits. L’erreur la plus fréquente. Sans requests, le scheduler empile les pods n’importe où. Sans limits, un pod peut consommer toutes les ressources d’un node. Résultat : des OOMKilled, des evictions et de l’instabilité.

Ignorer les readiness probes. Sans readiness probe, Kubernetes envoie du trafic à un pod dès qu’il démarre, même si le modèle n’est pas encore chargé. Résultat : erreurs 503 pendant le cold start.

YAML à la main sans GitOps. Gérer des manifests Kubernetes manuellement avec kubectl apply est intenable à grande échelle. Adoptez une approche GitOps (ArgoCD, Flux) où les manifests sont dans Git et synchronisés automatiquement avec le cluster.

Un seul namespace pour tout. Mélanger dev, staging et production dans le même namespace empêche toute isolation de ressources et de permissions. Utilisez des namespaces séparés dès le début.

Ne pas sauvegarder etcd. Sur un cluster self-managed, une panne etcd sans backup est catastrophique. Sauvegardez régulièrement et testez la restauration.

Questions fréquentes sur Kubernetes

Quelle est la différence entre Docker et Kubernetes ?

Docker construit et exécute des conteneurs individuels. Kubernetes orchestre des clusters de conteneurs : il décide où placer chaque conteneur, combien en maintenir, comment distribuer le trafic, et comment réagir aux pannes. Docker est l’outil de build et d’exécution locale, Kubernetes est l’outil de déploiement et de gestion en production. Vous utilisez Docker pour créer vos images, Kubernetes pour les déployer à grande échelle. Les deux sont complémentaires.

Kubernetes est-il nécessaire pour le machine learning ?

Pas pour un prototype ou un petit projet. Mais dès que vous avez plusieurs modèles en production, des besoins d’auto-scaling GPU, ou des pipelines ML automatisés, Kubernetes devient le choix naturel. KServe (model serving), Kubeflow (pipelines ML), et le NVIDIA GPU Operator rendent Kubernetes particulièrement adapté aux workloads MLOps. Si la complexité vous freine, un service managé (EKS, GKE, AKS) élimine la gestion du control plane.

Quelle version de Kubernetes utiliser ?

Utilisez la version stable la plus récente. En mars 2026, c’est Kubernetes 1.35.2 (avec v1.36 prévu pour avril 2026). Kubernetes supporte les 3 dernières versions mineures (politique N-2), chaque version étant supportée pendant 14 mois. Les cloud providers managés suivent généralement avec 1-2 versions de retard. Mettez à jour régulièrement pour les patches de sécurité.

EKS, GKE ou AKS : lequel choisir ?

Le critère principal est votre cloud provider existant. Si vous êtes sur AWS, utilisez EKS. Sur GCP, GKE (GKE Autopilot est particulièrement pratique). Sur Azure, AKS. Le multi-cloud est possible mais ajoute de la complexité. GKE est souvent considéré comme le plus mature en termes de fonctionnalités (Autopilot, TPU natif, Managed OpenTelemetry). EKS a l’avantage de l’intégration AWS (IAM, Fargate). AKS s’intègre bien avec Azure AD et l’écosystème Microsoft.

Combien coûte Kubernetes ?

Kubernetes lui-même est gratuit (open source). Le coût vient de l’infrastructure : les nodes workers (instances cloud), le stockage, le réseau, et les GPU. Les services managés facturent en plus le control plane : EKS ~73 $/mois par cluster, GKE Standard est gratuit (Autopilot facturé par pod), AKS est gratuit pour le control plane. Le coût total dépend de la taille de vos workloads. Pour un cluster ML avec 3 nodes GPU A100, comptez 5 000 à 15 000 $/mois selon l’utilisation. L’auto-scaling et le scale-to-zero (via KServe) sont les leviers principaux de réduction des coûts.