Kubernetes : comprendre l'orchestrateur de conteneurs.

Selon l'enquête annuelle de la CNCF publiée en janvier 2026, 82 % des utilisateurs de conteneurs font désormais tourner Kubernetes en production. Cet article explique ce qu'est Kubernetes, comment un cluster fonctionne, quels objets manipuler au quotidien et à quelles conditions l'outil tient ses promesses.

01Qu'est-ce que Kubernetes ?

Kubernetes est une plateforme open source d'orchestration de conteneurs. Elle automatise le déploiement, la mise à l'échelle et la gestion d'applications conteneurisées sur un ensemble de machines, appelé cluster. Le nom vient du grec et désigne le timonier ; on l'abrège souvent en K8s.

Le projet est né chez Google, qui l'a ouvert en 2014 en s'inspirant de son orchestrateur interne Borg. La version 1.0 est sortie en 2015, en même temps que la création de la Cloud Native Computing Foundation (CNCF), à qui le projet a été confié. Kubernetes publie aujourd'hui trois versions mineures par an : la version 1.37 est sortie fin août 2026, la 1.38 est attendue en décembre. Chaque version reçoit des correctifs pendant environ quatorze mois.

Le principe de l'état désiré

Tout Kubernetes repose sur une idée : on décrit l'état souhaité, et le système se charge de l'atteindre puis de le maintenir. Concrètement, on déclare qu'il doit exister trois exemplaires d'une application dans telle version, et Kubernetes enchaîne lui-même les actions nécessaires. Des contrôleurs comparent en permanence cet état désiré avec la réalité du cluster et agissent dès qu'un écart apparaît.

Cette boucle de réconciliation explique à la fois la puissance de l'outil et la plupart des surprises des débutants.

02L'architecture d'un cluster

Un cluster se compose de deux parties : le plan de contrôle, qui prend les décisions, et les nœuds de travail, qui exécutent les applications.

Le plan de contrôle

• kube-apiserverLa porte d'entrée unique du cluster. Tout passe par lui : les commandes kubectl, les pipelines CI/CD et les composants internes.
• etcdLa base clé-valeur qui stocke l'état complet du cluster. Sa sauvegarde est la première chose à vérifier sur un cluster autogéré.
• kube-schedulerIl choisit sur quel nœud placer chaque nouveau pod, en fonction des ressources demandées et des contraintes déclarées.
• kube-controller-managerIl fait tourner les boucles de réconciliation décrites plus haut.

Les nœuds de travail

Chaque nœud exécute un kubelet, l'agent qui démarre les conteneurs et surveille leur état, un composant réseau comme kube-proxy, et un runtime de conteneurs comme containerd ou CRI-O. Depuis la version 1.24 et le retrait du dockershim, Kubernetes passe exclusivement par l'interface standard CRI ; les images construites avec Docker restent pleinement compatibles.

Sur les offres managées comme GKE chez Google, EKS chez AWS ou AKS chez Azure, le fournisseur opère le plan de contrôle. L'équipe se concentre alors sur les nœuds et sur les applications.

03Les objets essentiels

Kubernetes se pilote à travers des objets décrits en YAML. Une dizaine d'entre eux couvre l'essentiel des besoins :

Un manifeste commenté

Voici à quoi ressemble le déploiement d'une API, avec son service :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: facturation-api
  namespace: facturation
spec:
  replicas: 3
  selector:
    matchLabels:
      app: facturation-api
  template:
    metadata:
      labels:
        app: facturation-api
    spec:
      containers:
        - name: api
          image: registry.exemple.fr/facturation-api:2.4.1
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080
          livenessProbe:
            httpGet:
              path: /health/live
              port: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: facturation-api
  namespace: facturation
spec:
  selector:
    app: facturation-api
  ports:
    - port: 80
      targetPort: 8080

Chaque ligne a sa raison d'être :

• replicas: 3
  Les trois réplicas assurent la continuité de service si un nœud tombe.
• image: …:2.4.1
  L'image porte une version précise, ce qui rend chaque déploiement reproductible.
• requests et limits
  Les requests indiquent au scheduler les ressources à réserver, et la limite mémoire protège les voisins d'une fuite.
• readinessProbe et livenessProbe
  La sonde de disponibilité retient le trafic tant que l'application n'est pas prête, celle de vivacité la redémarre si elle se bloque.

Quatre commandes suffisent ensuite pour déployer, suivre et, si besoin, revenir en arrière :

kubectl apply -f facturation-api.yaml
kubectl rollout status deployment/facturation-api -n facturation
kubectl get pods -n facturation -o wide
kubectl rollout undo deployment/facturation-api -n facturation

04Ce que Kubernetes apporte en pratique

Les bénéfices se mesurent dans les situations où l'exploitation classique souffre le plus. Les exemples suivants sont des scénarios illustratifs.

• 01
  L'auto-réparation

  Un serveur tombe en panne à trois heures du matin. Les pods qu'il hébergeait sont replacés sur les nœuds restants en quelques minutes, et l'astreinte découvre l'incident le lendemain dans les journaux.

• 02
  La mise à l'échelle

  Une enseigne voit son trafic se multiplier pendant les soldes. L'HorizontalPodAutoscaler ajoute des pods à mesure que la charge monte, puis les retire quand elle retombe ; la version 1.37 fait même passer en beta la réduction à zéro pod pour certaines métriques.

• 03
  Les mises à jour sans coupure

  Un Deployment remplace les pods progressivement et ne poursuit que si les nouvelles versions répondent correctement. En cas de problème, un rollback restaure la version précédente.

• 04
  La portabilité

  Les mêmes manifestes tournent sur GKE, EKS, AKS, OpenShift ou un cluster installé dans votre datacenter, ce qui limite la dépendance à un fournisseur.

• 05
  Les charges d'IA

  La CNCF indique que 66 % des organisations qui hébergent des modèles d'IA générative utilisent Kubernetes pour tout ou partie de leurs charges d'inférence.

05Les conditions pour en tirer parti

Faut-il pour autant faire tourner toutes ses applications sur Kubernetes ? L'outil est puissant, et cette puissance a un coût d'apprentissage et d'exploitation. Cinq points méritent une attention particulière avant de se lancer.

1. Le bon niveau de complexité.

   Pour quelques conteneurs sans contrainte forte, un service managé comme Cloud Run, Azure Container Apps ou Amazon ECS suffit souvent. Kubernetes se justifie quand le nombre de services, d'équipes ou d'environnements augmente.

2. Le rythme des mises à jour.

   Trois versions par an et environ quatorze mois de correctifs chacune : un cluster qui n'est jamais mis à jour se retrouve hors support en un peu plus d'un an.

3. La sécurité.

   Contrôle d'accès par rôles (RBAC), politiques réseau, standards de sécurité des pods et gestion des secrets demandent une vraie conception. Par défaut, les Secrets sont seulement encodés en base64 et stockés en clair dans etcd tant que le chiffrement au repos n'est pas activé.

4. L'observabilité.

   Métriques avec Prometheus, tableaux de bord avec Grafana, journaux centralisés : sans eux, un cluster devient une boîte noire.

5. Les coûts.

   Des requests surdimensionnées réservent des ressources jamais utilisées. Le suivi FinOps des clusters fait partie de l'exploitation courante.

06L'écosystème à connaître

Kubernetes forme le socle d'un écosystème riche, porté en grande partie par la CNCF :

• HelmLe gestionnaire de paquets, qui regroupe les manifestes d'une application dans un chart paramétrable.
• Argo CD et FluxLes outils GitOps, qui synchronisent le cluster avec l'état décrit dans un dépôt Git.
• Prometheus et GrafanaPour les métriques et les tableaux de bord.
• cert-managerIl obtient et renouvelle automatiquement les certificats TLS.
• Istio ou LinkerdLes service mesh, qui chiffrent et observent les échanges entre services.

La démarche la plus sûre consiste à avancer par étapes :

1. 1
   Un cluster managé
2. 2
   Des manifestes versionnésdans Git
3. 3
   Une chaîne de déploiementautomatisée
4. 4
   Les briques avancéescomme le service mesh, seulement ensuite

Kubernetes tient ses promesses d'auto-réparation, de mise à l'échelle et de déploiements sans coupure lorsque son adoption s'accompagne d'une montée en compétences des équipes et d'une exploitation rigoureuse, version après version.

Article rédigé par la communauté DryOps

DryOps rassemble nos experts de l'automatisation et de la production autour d'une idée simple : une tâche faite deux fois mérite d'être automatisée. Ses membres mettent en commun scripts, méthodes et retours de mission pour fiabiliser les systèmes d'information de nos clients et les rendre plus simples à exploiter.