ReplicaSet Kubernetes : comprendre ce que crée un Deployment

Un ReplicaSet garantit qu’un nombre défini de Pods reste toujours actif. Si un Pod disparaît, le ReplicaSet le recrée automatiquement. En pratique, vous ne créez jamais de ReplicaSet directement — c’est le Deployment qui s’en charge.

Ce guide vous aide à comprendre ce qui se passe sous le capot quand vous créez un Deployment.

À retenir immédiatement

Les ReplicaSets sont rarement créés manuellement. Utilisez un Deployment qui crée et gère les ReplicaSets pour vous, avec en bonus les mises à jour progressives et les rollbacks.

Conseil : lisez d’abord le guide Deployments pour comprendre le contexte d’usage le plus courant des ReplicaSets.

ReplicaSet ou Deployment ?

Un ReplicaSet maintient un nombre donné de Pods en fonctionnement. Un Deployment ajoute par-dessus la gestion des versions, des rolling updates et des rollbacks. En pratique, on manipule surtout des Deployments, qui créent et pilotent les ReplicaSets automatiquement.

Ressource	Rôle principal
ReplicaSet	Maintenir un nombre donné de Pods
Deployment	Gérer les versions, mises à jour et rollbacks via des ReplicaSets

Glissez pour voir

Ce que vous allez apprendre

• Comprendre le rôle du ReplicaSet dans l’architecture Kubernetes
• Observer les ReplicaSets créés automatiquement par vos Deployments
• Distinguer ce que fait le ReplicaSet de ce que fait le Deployment
• Diagnostiquer un problème au niveau du ReplicaSet

Ce qu’est un ReplicaSet

Un ReplicaSet est un contrôleur Kubernetes avec une mission simple : maintenir N Pods identiques en fonctionnement.

Son rôle :

1. Surveiller les Pods correspondant à son selector
2. Compter combien tournent actuellement
3. Créer ou supprimer des Pods pour atteindre le nombre demandé (replicas)

Analogie

Imaginez un responsable d’équipe qui doit toujours avoir 3 personnes en poste. Si quelqu’un part, il embauche aussitôt un remplaçant. Le ReplicaSet fait la même chose avec les Pods.

Voir les ReplicaSets créés par un Deployment

Quand vous créez un Deployment, Kubernetes crée automatiquement un ReplicaSet. Vérifiez-le :

kubectl get deployments
kubectl get rs

Exemple de sortie :

NAME           READY   UP-TO-DATE   AVAILABLE
nginx-deploy   3/3     3            3

NAME                      DESIRED   CURRENT   READY   AGE
nginx-deploy-7d545bdd84   3         3         3       5m

Le nom nginx-deploy-7d545bdd84 combine le nom du Deployment + un hash du template Pod.

La chaîne de propriété

Vérifiez le propriétaire d’un ReplicaSet :

kubectl get rs nginx-deploy-7d545bdd84 -o jsonpath='{.metadata.ownerReferences[0].kind}'
# Résultat : Deployment

Et le propriétaire d’un Pod :

kubectl get pods -l app=nginx -o jsonpath='{.items[0].metadata.ownerReferences[0].kind}'
# Résultat : ReplicaSet

Pourquoi un Deployment crée un nouveau ReplicaSet à chaque mise à jour

Quand vous changez l’image d’un Deployment, Kubernetes crée un nouveau ReplicaSet au lieu de modifier l’existant :

kubectl set image deployment/nginx-deploy nginx=nginx:1.25
kubectl get rs -l app=nginx

Résultat :

NAME                      DESIRED   CURRENT   READY
nginx-deploy-795dcb6589   3         3         3      # nouveau
nginx-deploy-7d545bdd84   0         0         0      # ancien, scale à 0

Pourquoi ? Le Deployment garde l’ancien ReplicaSet (avec 0 replicas) pour permettre un rollback instantané. C’est lui qui stocke l’historique des révisions.

Anatomie d’un ReplicaSet

Un ReplicaSet contient 3 éléments essentiels :

Champ	Description	Exemple
replicas	Nombre de Pods à maintenir	3
selector	Labels pour identifier les Pods gérés	app: nginx
template	Modèle de Pod à créer	Image, ports, etc.

Glissez pour voir

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx   # DOIT correspondre au selector
    spec:
      containers:
      - name: nginx
        image: nginx:1.24

matchLabels obligatoire

Les labels dans template.metadata.labels doivent correspondre au selector.matchLabels. Sinon, Kubernetes refuse de créer le ReplicaSet.

Selector immutable

En pratique, le selector d’un ReplicaSet ne doit pas être modifié après création. Une erreur de sélection peut provoquer des comportements difficiles à diagnostiquer.

Le selector : comment le ReplicaSet trouve ses Pods

Le selector est la règle qui définit quels Pods appartiennent au ReplicaSet. Le ReplicaSet surveille uniquement les Pods qui ont les labels correspondants.

matchLabels (simple)

selector:
  matchLabels:
    app: nginx
    environment: production

Équivalent à : “sélectionne les Pods où app=nginx ET environment=production”.

matchExpressions (avancé)

Kubernetes prend aussi en charge des sélecteurs plus complexes (In, NotIn, Exists, DoesNotExist). Pour les détails, consultez le guide Labels et Selectors.

Ce que le ReplicaSet fait (et ne fait pas)

Ce qu’il fait

Action	Comportement
Pod supprimé ou absent	Crée un nouveau Pod pour revenir à l’état souhaité
Scale up demandé	Crée les Pods manquants
Scale down demandé	Supprime les Pods excédentaires

Glissez pour voir

Ce qu’il ne fait PAS

Limitation	Conséquence
Mise à jour des Pods	Modifier le template n’affecte pas les Pods existants
Rolling update	Pas de mise à jour progressive
Rollback	Pas d’historique des versions

Glissez pour voir

Démonstration : si vous modifiez l’image dans un ReplicaSet existant :

kubectl set image rs/nginx-rs nginx=nginx:1.25
kubectl get pods -o jsonpath='{.items[*].spec.containers[0].image}'
# Résultat : nginx:1.24 nginx:1.24 nginx:1.24

Les Pods existants gardent l’ancienne image. Seuls les nouveaux Pods (si un Pod est supprimé et recréé) utiliseront la nouvelle image.

Démonstration, pas bonne pratique

Modifier directement un ReplicaSet est surtout utile pour comprendre son comportement. En production, on évite cette approche et on laisse le Deployment créer un nouveau ReplicaSet à partir d’un nouveau template.

C'est pourquoi on utilise des Deployments

Le Deployment résout ce problème en créant un nouveau ReplicaSet à chaque mise à jour, puis en transférant progressivement les Pods vers ce nouveau ReplicaSet.

Cas particulier : créer un ReplicaSet manuellement

Dans la pratique, ce cas est rare. Il peut servir à des démonstrations, à des tests ou à la compréhension du fonctionnement interne des Deployments.

replicaset-demo.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: echo-rs
spec:
  replicas: 3
  selector:
    matchLabels:
      app: echo
  template:
    metadata:
      labels:
        app: echo
    spec:
      containers:
      - name: echo
        image: hashicorp/http-echo:1.0.0

kubectl apply -f replicaset-demo.yaml
kubectl get rs echo-rs

Observer et inspecter un ReplicaSet

Vue d’ensemble

kubectl get rs

NAME       DESIRED   CURRENT   READY   AGE
echo-rs    3         3         3       2m

Colonne	Signification
DESIRED	Nombre de Pods demandé (replicas)
CURRENT	Nombre de Pods créés
READY	Nombre de Pods prêts (passant les probes)

Glissez pour voir

Détails complets

kubectl describe rs echo-rs

Informations clés à regarder :

• Selector : labels utilisés pour identifier les Pods
• Replicas : X current / Y desired
• Events : historique des actions (SuccessfulCreate, SuccessfulDelete)

Scaler un ReplicaSet

kubectl scale rs echo-rs --replicas=5

Conflit avec Deployment

Si le ReplicaSet est géré par un Deployment, celui-ci va immédiatement remettre le nombre de replicas à sa valeur. Utilisez kubectl scale deployment/... à la place.

Debug : problèmes au niveau ReplicaSet

1. Vérifier l’état du ReplicaSet

   kubectl get rs

   Si READY < DESIRED, des Pods ne démarrent pas.

2. Lister les Pods associés

   kubectl get pods -l app=echo

   Identifiez les Pods en Pending, CrashLoopBackOff ou Error.

3. Inspecter les événements du ReplicaSet

   kubectl describe rs echo-rs | grep -A 20 Events

4. Diagnostiquer un Pod spécifique

   kubectl describe pod <nom-du-pod>
   kubectl logs <nom-du-pod>

Problèmes courants

Symptôme	Cause probable	Solution
CURRENT < DESIRED	Quota de ressources atteint	Vérifier kubectl describe ns <namespace>
Pods en Pending	Pas de node disponible	kubectl get nodes, libérer des ressources
Pods en CrashLoopBackOff	Erreur applicative	Vérifier les logs du Pod
selector ne match pas	Labels incohérents	Comparer selector et template.labels

Glissez pour voir

À retenir

1. Un ReplicaSet maintient N Pods identiques, mais ne gère pas les mises à jour
2. Un Deployment crée et gère les ReplicaSets automatiquement
3. À chaque mise à jour, le Deployment crée un nouveau ReplicaSet (rollback possible)
4. Le selector lie le ReplicaSet à ses Pods via les labels
5. En pratique, vous n’interagissez pas directement avec les ReplicaSets

Prochaines étapes

Deployments Créer et mettre à jour vos applications avec rolling updates et rollbacks

Services Exposer vos Pods sur le réseau du cluster

Labels et Selectors Comprendre le système d'étiquetage de Kubernetes

×

📖 Voir la documentation →