Kubernetes : parcours kubeadm, Helm et workloads (2026)
À la fin de cette page pilier, vous saurez quel problème Kubernetes résout, dessiner le control plane et les nœuds, déployer un premier Deployment + Service en lab, et suivre le parcours du menu (kubeadm, workloads, config, sécurité, opérations).
Niveau : Débutant → Intermédiaire · Temps estimé : 60–80 min · Versions cibles : Kubernetes 1.31+ · images
registry.k8s.io· Dernière vérification : 2026-09-13
Prérequis
- Avoir fini le socle Docker (images, Dockerfile, au moins Compose)
- Bases Linux et YAML
- Un laptop pour kind / minikube, ou deux VM Ubuntu 24.04 pour kubeadm (voie CKA)
- Coût estimé : 0 € en lab local ; le cloud managé (EKS/AKS/GKE) est hors de ce hub
Kubernetes est le « système d’exploitation du cloud » : il place des conteneurs sur une flotte, les maintient, les connecte, les met à l’échelle et déroule les versions. Ce hub traduit et enrichit le contenu live anglais (architecture, quickstart, carte de 40+ leçons) en français pédagogique, sans supprimer les commandes utiles.
Ce que nous allons construire
Hub Kubernetes (menu DevOps)
├── Pourquoi K8s (état désiré, réconciliation)
├── Architecture : API, etcd, scheduler, kubelet, CNI
├── Quickstart : kind + Deployment + Service
├── Carte du parcours (leçons live)
├── Erreurs fréquentes + FAQ (5)
└── Suite : EKS / CKA / GitOps
Étape 1 — Quel problème Kubernetes résout
Lancer un conteneur sur un hôte est facile. En faire tourner des centaines, redémarrer ceux qui meurent, les déplacer si un nœud tombe, répartir le trafic, injecter config et secrets, de la même façon sur un laptop et dans trois clouds : ce n’est plus du Docker seul. Kubernetes transforme cela en état désiré déclaratif : vous décrivez ce qui doit exister ; le control plane réconcilie en continu.
Sans ce contrat, chaque serveur redevient un flocon (scripts SSH, Compose oublié, rebuild à la main). Avec ce contrat, le Capstone peut plus tard quitter le mono-nœud Docker pour un Deployment.
| Option | Idéal pour | Note |
|---|---|---|
| kind / minikube | Apprendre, CI | Une machine, jetable |
| k3s / MicroK8s | Lab, edge | Binaire léger |
| kubeadm | Comprendre, CKA, on-prem | Vous gérez tout, y compris les upgrades |
| EKS / AKS / GKE | Prod cloud | Control plane managé |
| OpenShift / Rancher | Plateformes entreprise | Kubernetes + opinions |
Kubernetes pour une seule petite app ? Souvent excessif. Compose ou un PaaS suffisent. Kubernetes paie quand il y a plusieurs services, plusieurs équipes, ou un besoin d’auto-healing.
Étape 2 — Architecture en cinq minutes
Deux zones : décision (control plane) et exécution (nœuds).
| Zone | Rôle | Composants |
|---|---|---|
| Control plane | Valide l’API, stocke l’état, place et réconcilie | API server, etcd, scheduler, controller-manager |
| Nœud | Exécute les Pods, réseau, runtime | kubelet, containerd (CRI), kube-proxy, CNI |
Le flux mental : kubectl parle à l’API ; l’API écrit dans etcd ; les contrôleurs voient l’écart ; le scheduler choisit un nœud ; le kubelet démarre les conteneurs. Le CNI (Calico, Cilium, Flannel…) donne une IP à chaque Pod. Détails : architecture côté brouillons internes, et les pages live etcd, CNI.
Les objets du quotidien :
| Objet | Rôle | Leçon live |
|---|---|---|
| Pod | Plus petite unité (un ou plusieurs conteneurs) | Pod overview |
| Deployment / ReplicaSet | N copies, rolling update, rollback | Deployment, ReplicaSet |
| Service | IP/DNS stable devant des Pods | Services |
| ConfigMap / Secret | Config et credentials | ConfigMaps, Secrets |
| Namespace | Partition logique | Namespaces |
| Volume / PVC | Stockage durable | Volumes |
| Ingress / Gateway | HTTP depuis l’extérieur | Services |
Leçons spécialisées : StatefulSet, static pods, Jobs.
Images système : registry.k8s.io, plus l’ancien registre déprécié.
Étape 3 — Quickstart (dix minutes avec kind)
curl -LO "https://dl.k8s.io/release/$(curl -Ls https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -m 0755 kubectl /usr/local/bin/kubectl
# installer kind depuis kind.sigs.k8s.io (binaire) ou go install
kind create cluster --name lab
kubectl cluster-info
kubectl get nodes
Manifeste minimal (ressources + probe — habitudes 2026) :
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels: { app: web }
template:
metadata:
labels: { app: web }
spec:
containers:
- name: nginx
image: nginx:1.27-alpine
ports: [{ containerPort: 80 }]
resources:
requests: { cpu: 50m, memory: 32Mi }
limits: { memory: 64Mi }
readinessProbe:
httpGet: { path: /, port: 80 }
---
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector: { app: web }
ports: [{ port: 80, targetPort: 80 }]
kubectl apply -f web.yaml
kubectl get pods -l app=web
kubectl port-forward svc/web 8080:80
# self-healing
kubectl delete pod -l app=web --wait=false
kubectl rollout status deployment/web
kubectl delete -f web.yaml
kind delete cluster --name lab
Voie CKA : installer kubeadm + Calico. Intro : Kubernetes introduction.
Carte du parcours (leçons live)
1. Cluster. Introduction · kubeadm + Calico · etcd · CNI.
2. Workloads. Pods · assignation aux nœuds · static pods · init containers · ReplicaSet · Deployment · Jobs · StatefulSet · probes.
3. Config, réseau, stockage. ConfigMaps · Secrets · Services · CoreDNS · Network Policies · Volumes · Namespaces · quotas.
4. Sécurité. Service accounts · RBAC · Pod Security.
5. Opérations. Helm · Kompose · Metrics Server · HPA · upgrade · OS nœuds · troubleshooting · Prometheus · Grafana · Dashboard.
Cloud : EKS intro, lab EKS. Socle : Docker, Linux.
Habitudes qui rendent un cluster tenable
Toujours poser requests et limits : le scheduler et les autoscalers en dépendent. Versionnez les manifests et appliquez-les par pipeline ou GitOps ; évitez l’édition en direct sur la prod. Namespaces + RBAC par équipe ; Network Policies restrictives là où ça compte. Readiness probe sur tout ce qui reçoit du trafic ; PodDisruptionBudget sur le stateux. Montez d’une version mineure à la fois et lisez les dépréciations : Kubernetes sort trois fois par an.
Commandes du quotidien : lister les Pods toutes namespaces, describe (les events sont en bas), logs du Deployment, exec, top (Metrics Server), explain pour la doc intégrée.
Comment utiliser ce hub (et ne pas se noyer)
Quarante leçons font peur. Ce hub est la boussole, pas le substitut de chacune. Lisez l’architecture et faites le quickstart kind dans la même session. Ensuite, choisissez une voie :
- Voie laptop : kind / minikube, Deployments, Services, ConfigMaps, un peu de RBAC. Assez pour comprendre le Capstone « et après Docker ».
- Voie CKA : kubeadm + Calico sur Ubuntu, etcd, CNI, upgrades, troubleshooting. Plus long, plus proche de l’examen et de l’on-prem.
- Voie cloud : seulement après avoir touché un cluster jetable. EKS/AKS cachent le control plane ; si vous n’avez jamais vu etcd, vous déboguez à l’aveugle.
Ne commencez pas par Helm, Prometheus et l’Ingress « pour faire pro ». Un Deployment + Service + probe + requests, versionné dans Git, vaut mieux qu’un chart copié. Helm arrive à l’étape opérations, quand la répétition justifie le template.
Pont avec le reste du menu DevOps
Git versionne les manifests. Maven/Docker produisent l’image que le Pod tire. Ansible (ou un cloud-init) peut préparer les nœuds kubeadm, mais le jour le jour du cluster passe par kubectl et, plus tard, GitOps. Jenkins peut kubectl apply ; préférez un pipeline qui applique un dossier plutôt qu’un script unique. Nagios ou un stack Prometheus surveille ensuite — après que le Service répond, pas avant.
En 2026, le piège classique est de « faire du Kubernetes » pour une appli qui tenait dans Compose. Ce hub vous le dit clairement : apprenez quand même les objets (vous les croiserez en entretien), mais ne forcez pas un cluster à trois nœuds pour un blog. La maturité, c’est de choisir l’orchestrateur, pas de le subir.
Documentez pour votre lab : version de kubectl, nom du cluster kind, namespace utilisé, et l’image exacte (pas latest). C’est la même hygiène que pour Docker, appliquée à un plan de contrôle.
Objets que vous toucherez vraiment (90 % du quotidien)
Oubliez un instant DaemonSet, CronJob et Gateway API. Quatre fichiers YAML couvrent la majorité des incidents juniors : un Deployment (réplicas, probe, resources), un Service (selector), un ConfigMap (URL, feature flag non secret), un Secret (créé hors Git ou via un outil, jamais collé en clair dans un tutoriel public). Ajoutez un Namespace pour ne pas polluer default. Quand cela est vert, vous êtes prêt pour les leçons réseau et stockage.
Le self-healing se démontre en une commande : supprimer un Pod et voir le ReplicaSet en recréer un. Le rolling update se démontre en changeant le tag d’image et en suivant rollout status. Le rollback se démontre en annulant. Ces trois gestes, plus que n’importe quel slide d’architecture, justifient Kubernetes après Docker.
Gardez les manifests dans le même dépôt que l’application quand le périmètre est petit (Capstone). Séparez-les plus tard si plusieurs équipes touchent le cluster. L’important est qu’un kubectl apply soit rejouable, pas qu’il vive dans l’historique d’un laptop.
Pourquoi ce hub existe (menu, pas un lab isolé)
Cette page est le pilier menu Kubernetes : elle oriente, elle ne remplace pas les quarante leçons. Si vous n’avez que quarante minutes, lisez l’architecture, lancez kind, appliquez le Deployment, cassez un Pod, observez le self-healing. Revenez ensuite par la carte. C’est ainsi que le site évite les stubs de 200 mots tout en restant une boussole, pas un dump.
Erreurs fréquentes
| Symptôme | Cause | Correction |
|---|---|---|
| ImagePullBackOff | Mauvais tag / registre | Vérifier le nom ; registry.k8s.io pour le système |
| CrashLoopBackOff | Process qui meurt | Logs + describe ; probes trop agressives |
| Pending | Resources / taints | Requests trop hauts ; nœud tainted |
| Service muet | Mauvais selector | Labels Pod = selector Service |
| Forbidden | RBAC | RoleBinding manquant |
| kind KO | Docker arrêté | Daemon Docker + mémoire |
Laboratoire : ce que vous devez retenir du quickstart
Si kind démarre et que trois Pods passent Running, vous avez déjà touché scheduler, kubelet et Service. Supprimez un Pod : un autre naît — ReplicaSet. Changez l’image : rollout. Annulez : undo. Ces trois gestes valent une heure de slides. Notez la version de kubectl, le nom du cluster, et l’image exacte dans un README de lab. Quand vous passerez à kubeadm, le contrat mental reste le même : état désiré, réconciliation, objets. Seuls changent le nombre de nœuds et la façon d’installer le control plane.
Ne gardez pas un cluster kind « précieux ». Détruisez-le, recréez-le. La peur d’effacer est le contraire de Kubernetes. En entretien, on vous demandera moins « c’est quoi etcd » que « comment tu sais qu’un Deployment a fini son rollout ». Ce hub vous y prépare, puis la carte vous envoie vers la leçon fine.
Encore une habitude : kubectl explain avant de copier un champ YAML inconnu. La doc est dans le cluster. Moins de blogs périmés, plus d’API réelle.
FAQ
1. Faut-il Docker Swarm d’abord ?
Non. Swarm est un après-midi utile, pas un prérequis. Voir Docker.
2. La CKA vaut-elle le coup ?
Oui pour un rôle DevOps/SRE : examen pratique. Ce parcours (setup, workloads, réseau, stockage, sécu, troubleshooting) suit son esprit.
3. Kubernetes pour un seul microservice ?
Souvent non. Compose ou un PaaS. Passez à K8s quand le nombre de services ou d’équipes explose.
4. kind ou kubeadm pour ce site ?
kind pour le quickstart de ce hub. kubeadm + Calico pour comprendre et viser la CKA.
5. Ansible a-t-il encore un sens avec Kubernetes ?
Oui : nœuds, bastions, bases, réseau, et parfois la collection Kubernetes. Voir Ansible.
Points clés à retenir
- Kubernetes réconcilie un état désiré sur une flotte.
- Control plane (API, etcd, scheduler, contrôleurs) + nœuds (kubelet, runtime, CNI).
- Pods, Deployments, Services, ConfigMaps/Secrets et Volumes couvrent l’essentiel.
- Parcours : setup → workloads → config/réseau/stockage → sécurité → opérations.
- Images officielles :
registry.k8s.io.
Pour aller plus loin
- Introduction puis kubeadm
- GitOps plus tard ; pont Terraform, AWS
- Hub parent DevOps
Maillage série DevOps
| ← Socle | Docker · Linux |
| → Suite | Ansible · Jenkins · Capstone |
| Aussi | CKA · EKS · Terraform |
