5.3Kubernetes en 20 minutes : Pod, Deployment, Service
L'essentiel en 30 secondes
- Trois objets, un principe : le Pod enveloppe les conteneurs, le Deployment maintient N Pods identiques et les met à jour, le Service donne une adresse stable devant des Pods interchangeables.
- On déclare, kubectl applique : manifests en YAML, commande d'application unique — le cluster maintient l'état voulu (Pod manquant = Pod recréé).
- Labo local d'abord : un seul cluster local suffit pour apprendre — tags d'image immuables, jamais de bricolage auto-hébergé en production sans équipe.
Mini-cas filé — Idir touche Kubernetes en local
Idir, devops junior à Alger, veut comprendre Kubernetes sans cloud ni facture : il crée un cluster local en une commande sur sa machine, y applique un Deployment (3 réplicas) et un Service, joint son appli en local, puis tue un Pod pour voir le Deployment le recréer. Suite du cas 5.2 — Idir passe du stack Swarm au premier déploiement Kubernetes.
Suite du cas 5.2 — Idir apprend sur cluster local avant toute idée de production.
1. Trois objets, un principe
Le Pod est l'enveloppe d'un ou plusieurs conteneurs co-localisés ; le Deployment maintient N Pods identiques et gère leurs mises à jour ; le Service donne une adresse stable devant des Pods interchangeables qui naissent et meurent. Idir retient la phrase : on joint le stable (Service), pas le mouvant (Pods).
On déclare l'état voulu en YAML (réplicas, image, sélecteurs, ports), on l'applique avec le client kubectl, et le cluster maintient cet état : c'est le principe déclaratif.
2. Le labo local
Pas de cloud pour débuter : un cluster local créé en une commande suffit, avec kubectl configuré dessus. Idir y applique ses manifests, vérifie ses 3 Pods, joint le Service en local (redirection de port pour le dev) — tableau de bord en option.
En production réelle, on vise un cluster managé : opérer soi-même un cluster exige une équipe. La règle : apprendre en local, produire en managé.
3. Appliquer, voir, exposer
Appliquer le fichier, lister Pods, Deployments et Services, joindre en local. La mise à jour = changer le tag d'image + ré-appliquer : rolling update automatique avec retour arrière possible. Idir tue un Pod et observe sa résurrection : l'orchestrateur maintient l'état déclaré.
Discipline des images : tags immuables dans les YAML, jamais de tag mouvant en déploiement — sinon on ne sait plus ce qui tourne vraiment.
🔎 Exemple concret — L'appli d'Idir en 3 réplicas sur cluster local
Déclarer, appliquer, joindre.
kubectl apply -f deploy.yaml
kubectl get pods
kubectl get deploy
kubectl get svc
kubectl port-forward svc/web 8080:80Lecture : 3 Pods derrière une adresse stable, jointure en local.
Leçon : tuer un Pod le fait renaître — l'état voulu est maintenu.
Vocabulaire de la section
- Pod
- La plus petite unité : l'enveloppe éphémère d'un ou plusieurs conteneurs.
Exemple simple : Idir voit ses Pods naître, mourir et renaître sur son cluster local.
Ce que ce n'est pas : une adresse stable à joindre durablement.
Réflexe : est-ce que je joins un Pod ou un Service ?
- Deployment
- Le contrôleur qui maintient N Pods identiques et gère leurs mises à jour.
Exemple simple : Idir déclare 3 réplicas : un Pod tué est recréé.
Ce que ce n'est pas : un conteneur lancé à la main sans contrôleur.
Réflexe : combien de réplicas ai-je déclarés ?
- Service
- L'adresse stable devant des Pods interchangeables.
Exemple simple : Idir joint le Service, pas les Pods mouvants.
Ce que ce n'est pas : l'adresse directe d'un Pod éphémère.
Réflexe : qu'est-ce qui reste stable quand les Pods bougent ?
- kubectl
- Le client en ligne de commande qui pilote le cluster.
Exemple simple : Idir applique, liste et inspecte avec kubectl.
Ce que ce n'est pas : une action manuelle sur chaque conteneur.
Réflexe : mon kubectl pointe-t-il sur le bon cluster ?
- Tag immuable
- Une étiquette d'image fixe qui désigne exactement une version.
Exemple simple : Idir met à jour en changeant de tag puis en ré-appliquant.
Ce que ce n'est pas : un tag mouvant qui change de contenu sans prévenir.
Réflexe : sais-je exactement quelle version tourne ?
En pratique — Kubernetes en local
- Créez un cluster local (une commande).
- Appliquez le Deployment + Service du modèle ci-dessous.
- Vérifiez les 3 Pods, joignez via redirection de port.
- Tuez un Pod et observez sa résurrection.
Script prêt à dire — proposer le labo Kubernetes
« Pour comprendre Kubernetes sans risque, je propose un labo local à Alger : un cluster sur ma machine, un Deployment à 3 réplicas avec tag immuable, un Service joint en local. On verra l'auto-réparation en tuant un Pod — aucune production touchée, aucune facture cloud. »
À dire au référent pour valider l'apprentissage en local avant tout projet cluster.
Modèle copier-coller — Deployment + Service génériques
K8S GENERIQUE — fichier deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: mon-registre/mon-app:stable
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: web
spec:
selector:
app: web
ports:
- port: 80
COMMANDES : kubectl apply -f deploy.yaml · kubectl get pods · kubectl port-forward svc/web 8080:80Solo / petit budget
Idir seul : un cluster local gratuit suffit — 3 réplicas, jointure locale.
TPE / équipe réduite
Démo partagée : l'un tue un Pod, l'autre constate la résurrection.
PME à Alger
Idir cale à Alger un atelier : chacun applique le manifest sur son poste.
Équipe qui démarre
Binôme : l'un écrit le YAML, l'autre vérifie sélecteurs et tags avant apply.
✓ Bonnes pratiques
- Apprenez sur cluster local, produisez en managé.
- Tags d'image immuables dans les YAML.
- Redirection de port pour le dev, vraie exposition en production.
✗ Pièges fréquents
- Tag mouvant dans un Deployment (on ne sait plus ce qui tourne).
- Cluster bricolé en prod sans équipe pour l'opérer.
- Confondre Pod éphémère et Service stable.
Points clés à retenir
- Pod = enveloppe éphémère, Deployment = réplicas, Service = adresse stable.
- On déclare en YAML, kubectl applique, le cluster maintient.
- La mise à jour = nouveau tag + ré-application, retour arrière possible.
- Apprendre en local, tags immuables, production en managé.
Défi 48h — appliquez demain
Appliquez le Deployment + Service générique (modèle ci-dessus) sur un cluster local : 3 Pods visibles, jointure locale OK, résurrection après suppression d'un Pod.
- Je peux décrire Pod, Deployment et Service en une phrase chacun.
- Mon déploiement local affiche 3 Pods derrière un Service.
- Je sais mettre à jour par nouveau tag + ré-application.
Questions fréquentes
Faut-il tout migrer sur Kubernetes après ce guide ?
Non : ce niveau donne les clés pour comprendre et décider. Beaucoup d'applis restent très bien sur Compose ou Swarm — Kubernetes n'est rentable que si le parc, les équipes et les exigences (autoscaling, multi-équipes) le justifient.
Par quelle certification commencer après ce guide ?
De façon générique : d'abord une certification centrée sur Docker qui couronne ce guide (images, réseaux, volumes, Compose, Swarm, sécurité), puis une certification Kubernetes si Kubernetes est votre cible. Les deux se préparent par des labs pratiques, pas par cœur.
Un Pod meurt. Que fait le Deployment ?