L'essentiel en une minute
Ce guide Kubernetes pour débutants s'adresse à vous si vous savez lancer un conteneur Docker et que le mot « orchestration » reste flou. Kubernetes ne remplace pas Docker : il décide où tournent vos conteneurs, les relance quand ils tombent et les met à jour sans coupure quand l'application est configurée pour cela.
L'article explique cinq objets, compare trois façons d'essayer sur votre machine, puis déroule un premier déploiement. Il repose sur les documentations officielles et sur l'enquête annuelle de la CNCF, consultées le 12 octobre 2026. C'est une synthèse documentaire : nous n'avons pas exécuté les commandes.
Points clés
- Kubernetes maintient un état désiré : vous décrivez ce que vous voulez dans un fichier, le cluster s'en rapproche en continu.
- Cinq objets suffisent pour commencer : Pod, Deployment, Service, Ingress et Namespace.
- La version courante est la 1.37, sortie le 26 août 2026. Sa fin de vie est annoncée au 28 octobre 2027, soit environ quatorze mois plus tard.
- Selon l'enquête 2025 de la CNCF, 82 % des organisations qui utilisent des conteneurs font tourner Kubernetes en production, contre 66 % en 2023.
- Pour un petit projet sur un seul serveur, Docker Compose reste plus simple.
Ce que Kubernetes fait que Docker ne fait pas
Docker fabrique et lance des conteneurs sur une machine, Kubernetes les répartit et les surveille sur plusieurs. La documentation officielle le définit comme une plateforme open source, portable et extensible, pour gérer des charges de travail et des services conteneurisés (présentation de Kubernetes, consultée le 12 octobre 2026).
Le nom vient du grec et signifie timonier. L'abréviation K8s compte les huit lettres entre le K et le s. Google a ouvert le code du projet en 2014, d'après la même page.
L'idée centrale est l'état désiré. Vous n'écrivez pas « lance ce conteneur », vous écrivez « je veux deux copies de cette image ». Kubernetes compare en permanence la réalité à cette description et corrige l'écart. La documentation en tire la répartition de charge, le redémarrage des conteneurs défaillants, les déploiements progressifs et la mise à l'échelle.
| Besoin | Docker seul | Docker Compose | Kubernetes |
|---|---|---|---|
| Lancer un conteneur | Oui | Oui | Oui, dans un Pod |
| Décrire plusieurs services dans un fichier | Non | Oui | Oui, en manifestes YAML |
| Répartir sur plusieurs machines | Non | Non | Oui |
| Remplacer un conteneur tombé | Politique de redémarrage locale | Politique de redémarrage locale | Oui, y compris sur un autre nœud |
| Mise à jour progressive et retour arrière | Non | Non | Oui, via le Deployment |
| Complexité à apprendre | Faible | Faible | Élevée |
Ce tableau est notre synthèse. Docker décrit Compose comme un outil pour définir et lancer des applications multi-conteneurs (documentation de Docker Compose). Si ces notions sont neuves, commencez par notre guide Docker pour débutants.
Une idée répandue est à corriger : Kubernetes ne dépend plus de Docker pour exécuter les conteneurs. Le composant qui faisait le lien, dockershim, a été retiré dans la version 1.24. Les nœuds utilisent des moteurs comme containerd ou CRI-O, et les images construites avec Docker continuent de fonctionner (FAQ officielle sur le retrait de dockershim, 17 février 2022).
Kubernetes ne compile pas votre code, ne fournit pas de base de données intégrée et n'impose pas de solution de supervision, précise la même présentation. Votre chaîne d'intégration continue reste à construire : notre guide pour automatiser ses déploiements couvre cette partie.
Où en est Kubernetes en octobre 2026
La version courante est Kubernetes 1.37, nom de code Garhwal, sortie le 26 août 2026, avec un correctif 1.37.1 daté du 15 septembre (page de la version 1.37, consultée le 12 octobre 2026). Le projet maintient les trois dernières versions mineures, soit 1.37, 1.36 et 1.35, et indique environ un an de correctifs par version (page des versions).
La fin de vie est annoncée au 28 février 2027 pour la 1.35, au 28 juin 2027 pour la 1.36 et au 28 octobre 2027 pour la 1.37, soit environ quatorze mois après la sortie de la 1.37 (page des versions). La 1.34 atteint sa fin de vie le 27 octobre 2026.
Un tutoriel qui affiche une version 1.2x décrit donc un cluster qui n'est plus maintenu. Les objets de base, eux, n'ont pas changé.
Côté adoption, la référence est l'enquête annuelle de la CNCF, la fondation qui héberge le projet. Son édition 2025, publiée le 20 janvier 2026, indique que 82 % des utilisateurs de conteneurs font tourner Kubernetes en production, contre 66 % en 2023 (rapport de la CNCF, PDF). La part des organisations qui utilisent des conteneurs pour la plupart ou la totalité de leurs applications en production passe de 41 % à 56 %.
Ces chiffres ont une limite. L'enquête compte 628 répondants, déjà familiers du cloud native, avec une marge d'erreur de 3,3 points à un niveau de confiance de 90 % (rapport de la CNCF, PDF). Le chiffre de 82 % porte sur les organisations qui utilisent des conteneurs, pas sur toutes les entreprises.
Un cluster en deux minutes
Un cluster Kubernetes, c'est un plan de contrôle qui décide et des nœuds qui exécutent. La documentation le dit en une phrase : un cluster se compose d'un plan de contrôle et d'un ou plusieurs nœuds de travail (composants de Kubernetes).
Les pièces à retenir, avec le rôle que leur donne cette page :
- kube-apiserver : expose l'API de Kubernetes. Toutes vos commandes passent par lui.
- etcd : la base clé-valeur qui stocke l'état du cluster.
- kube-scheduler : choisit un nœud pour chaque nouveau Pod.
- kube-controller-manager : fait tourner les boucles qui ramènent l'état réel vers l'état désiré.
- kubelet : sur chaque nœud, vérifie que les Pods tournent.
Vous parlez au cluster avec kubectl, l'outil en ligne de commande officiel (outils d'installation). Sa version doit rester à une version mineure au plus de celle du serveur d'API (politique d'écart de versions).
Le vocabulaire Kubernetes pour débutants en 5 objets
Cinq objets couvrent l'essentiel d'une application web : le Pod l'exécute, le Deployment la maintient en vie, le Service lui donne une adresse stable, l'Ingress l'ouvre au trafic HTTP, le Namespace la range.
| Objet | Rôle en une phrase | Vous l'écrivez vous-même ? |
|---|---|---|
| Pod | Un ou plusieurs conteneurs qui partagent réseau et stockage | Rarement |
| Deployment | Maintient N copies d'un Pod et gère les mises à jour | Oui |
| Service | Adresse réseau stable devant des Pods qui changent | Oui |
| Ingress | Règles HTTP et HTTPS depuis l'extérieur vers les Services | Oui, avec un contrôleur installé |
| Namespace | Cloison logique pour ranger et isoler des ressources | Plus tard |
Le Pod
Le Pod est la plus petite unité que Kubernetes déploie. C'est un groupe d'un ou plusieurs conteneurs qui partagent le stockage et le réseau (documentation des Pods).
Deux points surprennent en venant de Docker. Un Pod est jetable : la documentation le décrit comme une entité relativement éphémère. Et vous ne créez presque jamais un Pod à la main, vous passez par un objet de plus haut niveau comme le Deployment.
Le Deployment
Le Deployment gère un ensemble de Pods identiques, en général pour une application sans état. Vous y décrivez un état désiré, et son contrôleur fait évoluer l'état réel vers cet état à un rythme contrôlé (documentation des Deployments).
C'est lui qui recrée un Pod supprimé, par l'intermédiaire d'un ReplicaSet que vous verrez apparaître avec kubectl get rs. Il remplace aussi les Pods progressivement lors d'un changement d'image et permet de revenir à la version précédente.
Le Service
Le Service résout un problème concret : les Pods changent d'adresse IP à chaque recréation. La documentation le définit comme une méthode pour exposer une application réseau qui tourne dans un ou plusieurs Pods (documentation des Services). Il cible les Pods par leurs étiquettes, pas par leur nom.
| Type de Service | Ce qu'il fait |
|---|---|
| ClusterIP (par défaut) | Adresse interne, joignable seulement depuis le cluster |
| NodePort | Ouvre un port fixe sur chaque nœud |
| LoadBalancer | Demande un répartiteur de charge externe au fournisseur cloud |
| ExternalName | Fait correspondre le Service à un nom DNS |
L'Ingress
L'Ingress expose des routes HTTP et HTTPS depuis l'extérieur du cluster vers des Services. Créer un Ingress seul n'a aucun effet : il faut un contrôleur d'Ingress installé dans le cluster (documentation de l'Ingress).
Deux informations récentes manquent dans beaucoup de tutoriels Kubernetes pour débutants. La même page indique que l'API Ingress est gelée et que le projet recommande désormais Gateway, une API installée en complément (documentation de Gateway API). L'Ingress reste stable.
Par ailleurs, le contrôleur Ingress NGINX, très présent dans les tutoriels, a été retiré par ses mainteneurs : sa maintenance était annoncée jusqu'en mars 2026, sans correctif de sécurité ensuite (blog de Kubernetes, 11 novembre 2025). Apprenez l'Ingress pour lire l'existant, et Gateway API pour un nouveau projet.
Le Namespace
Le Namespace isole des groupes de ressources dans un même cluster : les noms doivent être uniques dans un Namespace, pas entre Namespaces (documentation des Namespaces). Un cluster neuf en contient quatre : default, kube-system, kube-public et kube-node-lease.
Pour un cluster de quelques utilisateurs à quelques dizaines, la même page indique que vous n'avez pas besoin d'en créer. Restez dans default pour apprendre.
Essayer en local avec minikube, kind ou K3s
Les trois outils donnent un vrai cluster sur une seule machine, et le bon choix dépend de ce que vous avez déjà installé. Avec Docker sur Windows ou macOS, minikube et kind sont les plus directs. Sur un serveur Linux, K3s se présente comme la distribution la plus légère des trois.
| Outil | Principe | Prérequis indiqué par l'éditeur | Commande de départ |
|---|---|---|---|
| minikube | Cluster local à un ou plusieurs nœuds, dans un conteneur ou une machine virtuelle | Docker ou un hyperviseur, 2 processeurs, 2 Go de mémoire libre, 20 Go de disque | minikube start |
| kind | Chaque nœud du cluster est un conteneur | Docker, Podman ou nerdctl | kind create cluster |
| K3s | Distribution allégée, binaire de moins de 100 Mo | Linux, 2 cœurs et 2 Go de mémoire pour un serveur | Script d'installation (ci-dessous) |
Sources : démarrage de minikube, démarrage rapide de kind, démarrage rapide de K3s et prérequis de K3s, consultés le 12 octobre 2026. Ces chiffres sont ceux des éditeurs, pas des mesures. Sous Linux, l'installation de minikube et de kind passe par un téléchargement décrit sur ces pages.
Installez aussi kubectl : brew install kubectl sur macOS (installation sur macOS), winget install -e --id Kubernetes.kubectl sur Windows (installation sur Windows). À défaut, minikube embarque le sien : préfixez chaque commande par minikube kubectl -- (kubectl dans minikube).
minikube est l'outil utilisé par le tutoriel officiel de Kubernetes. Il s'installe avec brew install minikube sur macOS et winget install Kubernetes.minikube sur Windows. Son tableau de bord s'ouvre avec minikube dashboard.
kind signifie Kubernetes in Docker. Il s'installe avec brew install kind ou winget install Kubernetes.kind. Sa page indique la version stable 0.33.0. Un fichier de configuration permet de créer un cluster à plusieurs nœuds.
K3s embarque containerd, CoreDNS, le contrôleur d'Ingress Traefik et un répartiteur de charge (documentation de K3s). Son installation tient en une commande, donnée par le démarrage rapide :
curl -sfL https://get.k3s.io | sh -
Le script installe un service système, kubectl et un fichier de configuration dans /etc/rancher/k3s/k3s.yaml. Lisez toujours un script avant de le passer à sh. Sur le serveur, la documentation indique k3s kubectl get nodes pour un premier essai (accès au cluster K3s).
Côté matériel, ces 2 Go de mémoire s'ajoutent à votre éditeur et à votre navigateur. Notre comparatif des ordinateurs portables pour développeur détaille les configurations adaptées aux conteneurs.
Un premier déploiement pas à pas
Ce premier déploiement est le cœur de tout parcours Kubernetes pour débutants. Il tient en huit étapes courtes, suivies du ménage. L'exemple utilise minikube. Avec kind, remplacez minikube start par kind create cluster et le ménage final par kind delete cluster ; l'étape Ingress, elle, est propre à minikube.
Étape 1. Démarrez le cluster et vérifiez que kubectl lui parle.
minikube start
kubectl get nodes
kubectl config current-context
Étape 2. Créez un fichier web.yaml. Il reprend la structure de l'exemple officiel de Deployment, avec deux copies d'un serveur nginx et un Service devant elles.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
labels:
app: web
spec:
replicas: 2
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:stable
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
ports:
- protocol: TCP
port: 80
targetPort: 80
Trois lignes portent toute la logique. replicas: 2 est l'état désiré. selector.matchLabels dit au Deployment quels Pods lui appartiennent, et doit correspondre aux étiquettes du modèle de Pod. Le selector du Service utilise la même étiquette pour trouver les Pods.
Étape 3. Appliquez le fichier et attendez la fin du déploiement.
kubectl apply -f web.yaml
kubectl rollout status deployment/web
kubectl get pods -o wide
kubectl get services
Étape 4. Ouvrez un accès. Sans type précisé, le Service est un ClusterIP, joignable seulement depuis le cluster. Pour l'ouvrir sur votre machine le temps d'un essai, la documentation propose le transfert de port (accès par transfert de port). La commande ne rend pas la main : ouvrez http://localhost:8080 dans un navigateur, puis arrêtez-la avec Ctrl+C.
kubectl port-forward service/web 8080:80
Étape 5. Vient le moment qui fait comprendre Kubernetes. Supprimez un Pod, puis affichez de nouveau la liste : le Deployment en recrée un pour revenir à deux copies.
kubectl get pods
kubectl delete pod NOM-DU-POD
kubectl get pods
Étape 6. Changez l'échelle, puis l'image, puis revenez en arrière. Ces commandes figurent dans la documentation des Deployments et dans l'aide-mémoire de kubectl. Dans set image, nginx est le nom du conteneur déclaré dans le manifeste. Un kubectl apply -f web.yaml ultérieur ramènera le Deployment à deux copies.
kubectl scale deployment/web --replicas=4
kubectl set image deployment/web nginx=nginx:mainline
kubectl rollout status deployment/web
kubectl rollout undo deployment/web
Étape 7. Quand un Pod ne démarre pas, trois commandes aident à trouver la cause : sa description, ses journaux et les événements du cluster.
kubectl describe pods NOM-DU-POD
kubectl logs NOM-DU-POD
kubectl get events
Étape 8. Pour aller jusqu'à l'Ingress, activez d'abord un contrôleur avec minikube addons enable ingress (démarrage de minikube). Enregistrez ensuite ce manifeste, qui suit le modèle minimal de la documentation, dans ingress.yaml.
Il sert ici à lire la structure d'un Ingress. D'après les pages de minikube, ce module installe le contrôleur Ingress NGINX, celui dont la maintenance s'est arrêtée : réservez-le à un essai local. La classe affichée dans l'exemple de minikube est nginx. Sur un autre cluster, remplacez-la par celle que montre kubectl get ingressclass.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web
spec:
ingressClassName: nginx
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web
port:
number: 80
Appliquez-le, puis attendez qu'une adresse apparaisse dans la colonne ADDRESS.
kubectl apply -f ingress.yaml
kubectl get ingress web
Avec Docker Desktop, la page de minikube demande d'ouvrir un autre terminal, d'y lancer minikube tunnel et d'utiliser l'adresse 127.0.0.1 à la place de celle affichée (démarrage de minikube).
Le ménage se fait dans l'ordre inverse.
kubectl delete -f ingress.yaml
kubectl delete -f web.yaml
minikube stop
minikube delete
L'étape suivante consiste à remplacer nginx par votre propre image. Une petite API REST avec Node.js et Express, une fois conteneurisée, fait un bon premier candidat.
Quand Kubernetes vaut le coup et quand c'est trop
Kubernetes se justifie quand vous avez plusieurs machines, plusieurs services et un besoin réel de disponibilité. Pour un site ou une API sur un seul serveur, il ajoute plus de travail qu'il n'en retire. Ce qui suit est notre lecture, pas une règle chiffrée.
Les signaux en faveur de Kubernetes :
- Plusieurs nœuds. Survivre à la perte d'une machine est le cœur du produit.
- Des mises à jour progressives. Le Deployment remplace les Pods peu à peu et sait revenir en arrière.
- Un trafic variable. Le HorizontalPodAutoscaler ajuste le nombre de copies à la demande. Il s'appuie sur un module à installer à part, Metrics Server (documentation de la mise à l'échelle horizontale).
- Plusieurs équipes. Les Namespaces et les quotas permettent de partager un cluster.
Les signaux contraires :
- Un seul serveur et deux ou trois services. Docker Compose suffit, sans plan de contrôle à maintenir.
- Personne pour l'exploiter. Avec douze à quatorze mois de correctifs par version, un cluster doit être mis à jour régulièrement.
- Un budget serré. Un cluster géré peut avoir un coût fixe avant le premier conteneur.
Sur ce dernier point, nous n'avons relevé qu'un tarif : Amazon EKS facture 0,10 $ par cluster et par heure en support standard, et 0,60 $ en support étendu, hors machines, stockage et réseau (tarifs d'Amazon EKS, consultés le 12 octobre 2026). Notre calcul : 0,10 $ sur 730 heures donne environ 73 $ par mois pour le seul plan de contrôle. Notre comparatif AWS, Azure et Google Cloud situe ces offres gérées, et notre guide de l'hébergement cloud pour développeurs présente des solutions plus simples.
Le frein principal n'est pas technique, d'après l'enquête de la CNCF. Parmi les difficultés liées aux conteneurs, les changements culturels dans l'équipe de développement arrivent en tête, citées par 47 % des répondants, devant le manque de formation et la sécurité, à 36 % chacun (rapport de la CNCF, PDF, 20 janvier 2026). Plusieurs réponses étaient possibles.
Verdict : apprenez Kubernetes en local, c'est gratuit. Ne l'installez en production que le jour où Docker Compose sur un serveur ne suffit plus. Si vous visez un poste orienté infrastructure, notre guide des certifications cloud aide à structurer la suite.
Ce que nous n'avons pas pu vérifier
Cet article est une synthèse de documentation, avec les limites que cela implique :
- L'exécution des commandes. Aucune n'a été lancée par nos soins. Elles sont reprises des documentations officielles, et une différence de version ou de système peut changer un détail.
- Le contenu de la version 1.37. Nous avons relevé sa date et son nom, pas le détail de ses nouveautés.
- Le statut de la version 1.34. La page des versions annonce sa fin de vie au 27 octobre 2026 et ne la compte déjà plus parmi les trois branches maintenues.
- Les tarifs de Google Kubernetes Engine et d'Azure Kubernetes Service. Nous n'avons pas pu relire ces pages. La fourchette de prix de l'ancienne version de l'article a été retirée faute de source.
-
L'étape Ingress. Le contrôleur et la classe
nginxsont déduits des exemples des pages de minikube, qui ne l'énoncent pas en une phrase. La commandekubectl get ingressclasssuit la forme générale de kubectl : nous ne l'avons pas trouvée écrite telle quelle dans les pages citées. - La consommation mémoire de K3s. La documentation de K3s annonce « moitié moins de mémoire » et explique avoir visé une installation de Kubernetes deux fois plus petite en empreinte mémoire, sans chiffre ni mesure.
- Les dates de collecte de l'enquête de la CNCF, absentes des passages que nous avons lus.
Questions fréquentes
Faut-il apprendre Docker avant Kubernetes ?
Oui, au moins les bases : construire une image, lancer un conteneur, publier un port. Kubernetes manipule des images de conteneurs, et celles construites avec Docker fonctionnent sur un cluster. En revanche, Kubernetes n'utilise plus Docker comme moteur d'exécution depuis le retrait de dockershim dans la version 1.24, selon la FAQ officielle.
Kubernetes est-il gratuit ?
Le logiciel est open source et les outils locaux comme minikube, kind et K3s ne coûtent rien. Les offres gérées peuvent être payantes : Amazon EKS affiche 0,10 $ par cluster et par heure en support standard, auxquels s'ajoutent les machines, le stockage et le réseau.
Quelle est la différence entre un Pod et un conteneur ?
Le conteneur exécute un processus à partir d'une image. Le Pod est l'enveloppe que Kubernetes déploie : un ou plusieurs conteneurs qui partagent le réseau et le stockage, d'après la documentation des Pods. Le plus souvent, un Pod contient un seul conteneur.
Minikube, kind ou K3s : lequel choisir pour débuter ?
Avec Docker déjà installé, minikube ou kind conviennent, et minikube est celui que suit le tutoriel officiel. Sur un serveur Linux, K3s s'installe en une commande. Ce que vous apprenez avec l'un vaut pour les autres : c'est l'intérêt d'apprendre en local.
À propos de l'auteur
Abdelilah Ourti est ingénieur IA et architecte logiciel. Il conçoit et déploie des applications web et des systèmes d'IA, et publie sur NeurauTech des guides et des comparatifs destinés aux développeurs francophones. Ses autres articles sont réunis sur sa page auteur.
Méthode. Synthèse documentaire fondée exclusivement sur des sources publiques : documentation et blog officiels de Kubernetes, documentations de minikube, de kind, de K3s et de Docker, consultées les 12 et 13 octobre 2026, rapport d'enquête 2025 de la CNCF, page de tarifs d'Amazon EKS. Les chiffres attribués à un éditeur sont signalés comme tels. Aucune commande n'a été exécutée pour cet article, aucun lien n'est affilié et aucune relation commerciale ne lie l'auteur aux éditeurs mentionnés.
Une erreur ou une commande périmée ? Écrivez à contact@neurautech.com : l'article sera corrigé et la date de mise à jour modifiée.
Dernière mise à jour : 12 octobre 2026. Première publication : 27 mai 2026.
Image : orbtal media (Unsplash License).
Top comments (0)