Kubernetes : définition, architecture et exemple de manifeste
L'orchestrateur open source qui déploie, met à l'échelle et répare automatiquement des conteneurs sur un cluster de machines : origine, architecture, objets clés, exemple de manifeste et écosystème.
Par Équipe Blent· Mis à jour le · 15 min de lecture· Niveau intermédiaire
Kubernetes en bref
- Abréviation
- K8s
- Origine
- Google, inspiré de son système interne Borg
- Lancement
- 2014 (version 1.0 en 2015)
- Gouvernance
- Cloud Native Computing Foundation (CNCF)
- Langage
- Go
- Licence
- Apache 2.0
- Offres managées
- Amazon EKS, Google GKE, Azure AKS
Définition : Kubernetes
Kubernetes, souvent abrégé K8s, est une plateforme open source d'orchestration de conteneurs. Elle automatise le déploiement, la mise à l'échelle, la mise en réseau et la réparation d'applications conteneurisées réparties sur un cluster de machines. L'utilisateur décrit l'état souhaité dans des manifestes déclaratifs, par exemple trois répliques d'une API exposées derrière un service, et Kubernetes compare en permanence cet état à la réalité pour corriger les écarts : il redémarre un conteneur défaillant, replanifie les charges d'un nœud en panne ou ajoute des répliques. Créé par Google en 2014 et confié à la Cloud Native Computing Foundation, Kubernetes est devenu le standard de l'infrastructure Cloud native.
En une phrase : Kubernetes maintient en permanence sur un cluster l'état que vous avez décrit pour vos conteneurs : nombre de répliques, réseau, configuration et mises à jour.
Dans cette définition
Qu'est-ce que Kubernetes ?
Kubernetes est un orchestrateur : il ne crée pas les conteneurs lui-même, il décide où et comment ils s'exécutent sur un ensemble de machines, et veille à ce qu'ils continuent de tourner. Là où Docker lance un conteneur sur une machine et où Docker Compose lance une application sur une machine, Kubernetes gère des centaines d'applications sur un cluster.
Le projet est né chez Google, qui exploitait depuis des années des conteneurs à très grande échelle avec un système interne baptisé Borg. Annoncé en juin 2014 et publié en open source, Kubernetes reprend les leçons de Borg dans un outil ouvert, écrit en Go. Ses fondateurs comptent notamment Joe Beda, Brendan Burns et Craig McLuckie. Lors de la sortie de la version 1.0, en juillet 2015, Google confie le projet à la toute nouvelle Cloud Native Computing Foundation (CNCF), créée sous l'égide de la Linux Foundation. En 2018, Kubernetes devient le premier projet « diplômé » de la CNCF. Une nouvelle version mineure sort environ trois fois par an.
Kubernetes s'est imposé comme la couche d'abstraction commune du Cloud. Tous les grands fournisseurs proposent une offre managée, et un vaste écosystème s'est construit au-dessus : packaging, GitOps, service mesh, MLOps. Pour une première prise en main, notre tutoriel Kubernetes guide la création d'un cluster local.
À retenir : avec Kubernetes, on ne lance pas des conteneurs, on déclare un état souhaité. Le cluster se charge de l'atteindre et de le maintenir, en continu.
L'architecture d'un cluster Kubernetes
Un cluster se compose de deux familles de machines : le control plane, qui prend les décisions, et les nœuds (workers), qui exécutent les applications.
Le control plane
- kube-apiserver : la porte d'entrée unique du cluster. Tous les composants, comme les utilisateurs via
kubectl, passent par son API REST. - etcd : une base clé-valeur distribuée et cohérente qui stocke l'état complet du cluster. Sa sauvegarde est vitale.
- kube-scheduler : affecte chaque nouveau Pod à un nœud, selon les ressources disponibles et les contraintes déclarées.
- kube-controller-manager : exécute les contrôleurs (Deployments, ReplicaSets, nœuds, Jobs…), chacun chargé de rapprocher un type d'objet de son état souhaité.
- cloud-controller-manager : fait le lien avec le fournisseur Cloud pour créer des load balancers, des disques ou gérer les machines.
Les nœuds
- kubelet : l'agent présent sur chaque nœud. Il reçoit la liste des Pods à exécuter et pilote le runtime pour les lancer.
- kube-proxy : maintient les règles réseau qui permettent d'atteindre les Services, parfois remplacé par le plugin réseau.
- Runtime de conteneurs : containerd ou CRI-O, appelés via la Container Runtime Interface.
S'y ajoutent des modules indispensables : un plugin réseau (CNI) comme Calico ou Cilium, et un DNS interne, généralement CoreDNS.
Les objets essentiels
| Objet | Rôle |
|---|---|
| Pod | Un ou plusieurs conteneurs qui partagent réseau et stockage, l'unité de base |
| Deployment | Maintient N répliques d'un Pod sans état et gère leurs mises à jour |
| StatefulSet | Variante pour les applications avec état (bases de données) |
| Service | Adresse stable et équilibrage de charge vers un groupe de Pods |
| Ingress | Routage HTTP(S) depuis l'extérieur vers les Services ; la Gateway API en est le successeur |
| ConfigMap | Configuration non sensible injectée dans les Pods |
| Secret | Données sensibles (mots de passe, jetons, certificats) |
| Namespace | Cloisonnement logique du cluster par équipe ou par environnement |
| PersistentVolumeClaim | Demande de stockage persistant pour un Pod |
Exemple : déployer une API avec un Deployment et un Service
Ce manifeste déploie trois répliques d'une API, leur injecte une configuration et les expose à l'intérieur du cluster derrière une adresse stable.
apiVersion: v1
kind: ConfigMap
metadata:
name: api-config
data:
LOG_LEVEL: "info"
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
labels:
app: api
spec:
replicas: 3
selector:
matchLabels:
app: api
template:
metadata:
labels:
app: api
spec:
containers:
- name: api
image: registry.example.com/equipe/api:1.4.2
ports:
- containerPort: 8000
envFrom:
- configMapRef:
name: api-config
resources:
requests:
cpu: 250m
memory: 256Mi
limits:
memory: 512Mi
readinessProbe:
httpGet:
path: /health
port: 8000
periodSeconds: 5
livenessProbe:
httpGet:
path: /health
port: 8000
initialDelaySeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: api
spec:
selector:
app: api
ports:
- port: 80
targetPort: 8000
Le Service sélectionne les Pods par leur label app: api : les autres applications du cluster appellent simplement http://api, et le trafic est réparti entre les répliques prêtes. Les requests aident le scheduler à placer les Pods, la readinessProbe retire du trafic un Pod qui n'est pas prêt, la livenessProbe redémarre un conteneur bloqué.
# Appliquer les manifestes et suivre le déploiement
kubectl apply -f api.yaml
kubectl rollout status deployment/api
kubectl get pods -l app=api
# Mettre à jour l'image : rolling update, puis retour arrière si besoin
kubectl set image deployment/api api=registry.example.com/equipe/api:1.5.0
kubectl rollout undo deployment/api
# Changer le nombre de répliques
kubectl scale deployment/api --replicas=5
# Constater la réconciliation : le Pod supprimé est aussitôt remplacé
kubectl delete pod -l app=api --wait=false
kubectl get pods -l app=api --watch
En pratique, ces manifestes sont rarement appliqués à la main : ils sont packagés avec Helm et synchronisés depuis Git selon l'approche GitOps.
À quoi sert Kubernetes ?
Kubernetes s'impose quand des applications conteneurisées doivent rester disponibles, évoluer souvent et absorber une charge variable.
Microservices en production
Déployer, exposer et mettre à jour indépendamment des dizaines de services, avec découverte et équilibrage de charge intégrés.
Haute disponibilité
Répartir les répliques sur plusieurs nœuds et zones, et remplacer automatiquement ce qui tombe en panne.
Mise à l'échelle automatique
Ajuster le nombre de Pods selon la charge, et le nombre de nœuds selon les besoins du cluster.
Plateforme interne
Offrir aux équipes un socle commun de déploiement, d'observabilité et de sécurité, base du Platform Engineering.
Machine learning et IA
Orchestrer l'entraînement distribué sur GPU, les pipelines ML et le service de modèles et de LLM.
Traitements batch
Exécuter des Jobs et CronJobs de traitement de données, de calcul ou de maintenance sur des ressources partagées.
Quels sont les avantages de Kubernetes ?
Kubernetes apporte une couche d'automatisation qui transforme un ensemble de serveurs en une plateforme unique, pilotée par du code.
- Auto-réparation : redémarrage, remplacement et replanification automatiques des conteneurs.
- Déploiements progressifs (rolling updates) et retour arrière en une commande.
- Mise à l'échelle horizontale manuelle ou automatique selon la charge.
- Modèle déclaratif idéal pour le versionnement, la revue de code et le GitOps.
- Portabilité entre Cloud publics, centres de données et postes locaux.
- Écosystème CNCF très riche et API extensible par des ressources personnalisées et des opérateurs.
Quelles sont les limites de Kubernetes ?
La puissance de Kubernetes a un coût en complexité, qu'il faut mettre en regard de la taille réelle du besoin.
- Courbe d'apprentissage longue : nombreux objets, concepts réseau et stockage spécifiques.
- Exploitation exigeante : mises à jour du cluster, sécurité, sauvegarde d'etcd, observabilité.
- Surdimensionné pour une petite application qu'un seul serveur suffit à héberger.
- Coûts difficiles à maîtriser sans dimensionnement des ressources ni suivi FinOps.
- Sécurité par défaut perfectible : RBAC, politiques réseau et gestion des secrets sont à configurer.
- Écosystème foisonnant, qui impose des choix d'outils à chaque couche.
Offres managées et distributions de Kubernetes
Installer et maintenir soi-même un control plane hautement disponible est un métier. La plupart des équipes délèguent cette partie.
| Option | Exemples | Ce que vous gérez | Idéal pour |
|---|---|---|---|
| Kubernetes managé | Amazon EKS, Google GKE, Azure AKS, offres d'OVHcloud ou Scaleway | Nœuds (ou pas, en mode serverless) et applications | La majorité des usages en production |
| Distribution d'entreprise | Red Hat OpenShift, Rancher | Le cluster, avec un outillage et un support éditeur | Grandes organisations, sur site ou hybride |
| Distribution légère | k3s, MicroK8s | Tout, avec une installation simplifiée | Edge, IoT, petits clusters |
| Installation manuelle | kubeadm | Tout, du control plane aux mises à jour | Besoins spécifiques, apprentissage approfondi |
| Cluster local | minikube, kind, k3d | Un cluster jetable sur votre poste | Développement et formation |
Au-dessus du cluster, l'écosystème couvre chaque besoin : Helm pour le packaging, Argo CD pour le GitOps, Prometheus pour le monitoring, Istio pour le service mesh. Côté données et IA, Kubernetes sert de socle à l'entraînement distribué sur GPU, à des plateformes comme Kubeflow et au service de modèles. Notre article Kubernetes et Machine Learning détaille ces usages.
Quand utiliser Kubernetes ?
Kubernetes se justifie par l'échelle et les exigences de disponibilité, pas par la mode. Posez-vous la question du nombre de services, de machines et d'équipes.
Kubernetes se justifie
- Plusieurs services doivent rester disponibles malgré les pannes.
- La charge varie et appelle une mise à l'échelle automatique.
- Plusieurs équipes déploient souvent sur une plateforme commune.
- Vous visez la portabilité entre fournisseurs Cloud.
Une solution plus simple suffit
- Une application unique tient sur un serveur : Docker Compose.
- L'équipe n'a pas les compétences pour exploiter un cluster.
- Un service managé de conteneurs ou de serverless couvre le besoin.
- Le trafic est faible et stable, sans exigence forte de disponibilité.
L'écosystème Kubernetes
Kubernetes se complète d'outils pour installer des applications, déployer en GitOps, observer, sécuriser et exécuter des charges spécialisées.
- CLI
kubectl
La ligne de commande officielle pour interroger et piloter un cluster.
- Packaging
Helm
Le gestionnaire de paquets de Kubernetes : des charts paramétrables et versionnés.
- GitOps
Argo CD
Synchronise en continu le cluster avec les manifestes stockés dans Git.
- Distribution
OpenShift
La plateforme Kubernetes d'entreprise de Red Hat, avec outillage et sécurité renforcés.
- Offres managées
Amazon EKS, GKE, AKS
Le control plane opéré par AWS, Google Cloud ou Microsoft Azure.
- Monitoring
Prometheus
Collecte des métriques du cluster et des applications, avec alerting.
- Service mesh
Istio
Chiffrement, routage avancé et observabilité des échanges entre services.
- MLOps
Kubeflow
Plateforme de machine learning qui s'exécute sur Kubernetes.
- Service de modèles
KServe
Expose des modèles de ML et des LLM comme des services auto-scalables.
Les concepts à connaître autour de Kubernetes
Ces notions éclairent ce que Kubernetes orchestre et les pratiques qui l'entourent.
- ConteneurL'unité d'exécution que Kubernetes regroupe en Pods et planifie sur les nœuds.
- GitOpsLa gestion du cluster par des manifestes versionnés dans Git et synchronisés automatiquement.
- Infrastructure as CodeLa description déclarative de l'infrastructure, du cluster lui-même jusqu'aux applications.
- Auto-scalingL'ajustement automatique des ressources à la charge, au niveau des Pods et des nœuds.
- Équilibrage de chargeLa répartition du trafic entre répliques, assurée par les Services et les Ingress.
- Déploiement CanaryUne stratégie de mise en production progressive, facilitée par Kubernetes.
Ressources pour approfondir Kubernetes
Trois articles du blog Blent pour démarrer, packager et appliquer Kubernetes au machine learning.
- Tutoriel
Tutoriel Kubernetes : premiers pas
Créer un cluster local et déployer sa première application pas à pas.
Lire l'article - Outil
Helm : gestion de packages sur Kubernetes
Packager, paramétrer et versionner ses déploiements avec des charts.
Lire l'article - MLOps
Kubernetes et Machine Learning
Pourquoi et comment exécuter entraînements et modèles sur un cluster.
Lire l'article
Questions fréquentes
Questions fréquentes
Expertise
À propos de l'auteur
Équipe Blent
Les ingénieurs et mentors Blent conçoivent, automatisent et mettent en production des infrastructures Cloud, et forment chaque année des centaines de professionnels au DevOps.
Sources et méthodologie
- Documentation officielle Kubernetes (kubernetes.io) : concepts, architecture, objets
- Verma et al., Large-scale cluster management at Google with Borg, EuroSys 2015
- Burns et al., Borg, Omega, and Kubernetes, ACM Queue, 2016
- Retours d'expérience des projets et formations Blent
Comment fonctionne Kubernetes ?
Kubernetes repose sur un principe déclaratif : vous décrivez le résultat attendu, des composants spécialisés se chargent de l'atteindre puis de le maintenir. Voici ce qui se passe lors du déploiement d'une application.
Décrire l'état souhaité
Un manifeste YAML décrit l'objet voulu : par exemple un Deployment de trois répliques d'une image donnée, avec ses ressources et ses sondes de santé.
Soumettre à l'API server
kubectl apply envoie le manifeste à l'API server, qui authentifie la requête, la valide, applique les politiques d'admission puis enregistre l'objet dans etcd.
Créer les objets dérivés
Le contrôleur des Deployments crée un ReplicaSet, dont le contrôleur crée à son tour trois Pods. À ce stade, les Pods existent mais ne sont affectés à aucune machine.
Planifier les Pods
Le scheduler choisit pour chaque Pod un nœud qui dispose des ressources demandées et respecte les contraintes d'affinité, de répartition et de tolérance.
Lancer les conteneurs
Sur chaque nœud retenu, le kubelet demande au runtime (containerd ou CRI-O) de tirer l'image et de démarrer les conteneurs, puis remonte leur état à l'API server.
Réconcilier en continu
Les contrôleurs comparent sans cesse l'état observé à l'état souhaité. Un Pod disparaît, un nœud tombe : un nouveau Pod est créé et planifié ailleurs, sans intervention.