Kubernetes 016 – Un Deployment c’est quoi ?

TL;DR

Un Deployment decrit un template de pods et un nombre de replicas. Kubernetes cree un ReplicaSet pour maintenir ces pods, puis gere les mises a jour lorsque le template change. En pratique, c’est l’objet le plus courant pour deployer une application web ou un worker stateless.

La video de reference

Video: https://www.youtube.com/watch?v=AFEU_mBbzr0

Elle arrive apres les pods et ReplicaSets pour montrer l’objet que l’on utilise reellement au quotidien.

Le role du Deployment

Un pod seul est fragile. Un ReplicaSet maintient un nombre de pods. Le Deployment ajoute la gestion de version du template et des mises a jour progressives.

Il permet de declarer: je veux trois instances de cette application, construites avec cette image, ces labels et ces ports.

Manifest minimal

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.25
          ports:
            - containerPort: 80

Appliquer et observer

kubectl apply -f deployment.yaml
kubectl get deploy
kubectl get rs
kubectl get pods -l app=web
kubectl describe deploy web

On voit alors trois niveaux: Deployment, ReplicaSet et pods. Le Deployment pilote le ReplicaSet, qui pilote les pods.

Spec, selector et template

Le champ spec.selector indique quels pods appartiennent au Deployment. Le champ spec.template decrit les pods a creer. Les labels du template doivent correspondre au selector.

Cette relation est centrale. Une incoherence de labels rend le controleur incapable de gerer correctement ses pods.

Mettre a l’echelle

kubectl scale deployment web --replicas=5
kubectl get pods -l app=web
kubectl scale deployment web --replicas=2

Le Deployment modifie le nombre de pods via son ReplicaSet actif.

Liens utiles

• Video: https://www.youtube.com/watch?v=AFEU_mBbzr0
• Deployments: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
• Workloads: https://kubernetes.io/docs/concepts/workloads/
• ReplicaSet: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/

FAQ

Deployment ou ReplicaSet ?

On utilise presque toujours Deployment. ReplicaSet est utile pour comprendre le mecanisme sous-jacent.

Deployment ou Pod ?

Pour une application durable, Deployment. Le pod direct sert surtout au test ou au debug.

Un Deployment expose-t-il l’application ?

Non. Il execute des pods. Pour l’acces reseau stable, il faut un Service.

Erreurs frequentes

• Oublier que le Deployment ne cree pas de Service.
• Modifier des pods a la main au lieu de modifier le template.
• Changer les labels sans verifier le selector.
• Utiliser latest sans strategie claire.

Pour pratiquer

kubectl create deployment web --image=nginx:1.25 --dry-run=client -o yaml > deployment.yaml
kubectl apply -f deployment.yaml
kubectl get deploy,rs,pods
kubectl delete pod -l app=web
kubectl get pods -l app=web -w

Supprimer un pod montre que le controleur le remplace automatiquement.

A retenir

Le Deployment est le point d’entree standard pour les workloads stateless. Il garde l’intention applicative dans un objet stable pendant que Kubernetes gere les pods concrets.

Notions et definitions

• Pod: plus petite unite deployable dans Kubernetes.
• Controleur: objet qui maintient un etat attendu, comme Deployment, ReplicaSet, DaemonSet ou StatefulSet.
• Reconciliation: boucle permanente qui compare l’etat reel et l’etat desire.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Un Deployment a trois replicas recree automatiquement un pod supprime afin de revenir a l’etat attendu declare dans sa specification.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Declarer le workload avec un manifest YAML ou une commande kubectl.
• Observer les pods crees et leurs labels.
• Lire les events pour comprendre scheduling, pulls d’images et redemarrages.
• Modifier le controleur plutot que les pods generes directement.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser le passage d’un conteneur isole a un workload controle par Kubernetes. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl get pods -o wide --show-labels
• kubectl describe pod <pod> pour lire scheduling, events et conditions
• kubectl rollout history deployment/<name> quand un Deployment est concerne

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• modifier un pod gere par un controleur au lieu de modifier le controleur lui-meme
• ignorer les events alors qu’ils expliquent souvent le probleme
• oublier que les labels sont le lien entre controleurs, pods et Services

Exercice conseille

Lancez un Deployment nginx a trois replicas, supprimez un pod manuellement, puis observez comment le controleur reconcilie l’etat attendu.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 017 – Rollouts : strategies, recreate, undo, pause.

Conclusion

Comprendre Deployment, c’est comprendre comment Kubernetes passe d’un pod isole a une application maintenue, scalable et mise a jour proprement.