Kubernetes 013 – ReplicaSet : c’est quoi et pourquoi ?

TL;DR

Un ReplicaSet maintient un nombre donne de pods correspondant a un selecteur. Si un pod disparait, il en cree un autre. Dans la pratique, on cree rarement des ReplicaSets directement: les Deployments les gerent pour ajouter les mises a jour progressives.

La video de reference

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

Elle marque le passage du pod isole vers les controleurs de workload.

Le probleme du pod seul

Un pod cree directement est fragile: si on le supprime, il disparait. Pour une application qui doit rester disponible, il faut un controleur capable de maintenir un nombre d’instances.

Le ReplicaSet repond a ce besoin: il surveille les pods qui correspondent a ses labels et ajuste le nombre de replicas.

Exemple simplifie

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx

Labels et selectors

Le coeur du ReplicaSet, c’est le selecteur. Il determine quels pods appartiennent au controleur. Une mauvaise correspondance entre selector.matchLabels et template.metadata.labels provoque des comportements inattendus ou des erreurs.

Liens utiles

• Video: https://www.youtube.com/watch?v=7gxiNW3nSW8
• ReplicaSet: https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
• Deployments: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
• Labels et selectors: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

FAQ

Faut-il creer des ReplicaSets directement ?

Pour apprendre, oui. En usage courant, on passe plutot par un Deployment.

Que se passe-t-il si je supprime un pod gere par ReplicaSet ?

Le ReplicaSet detecte qu’il manque un replica et cree un nouveau pod.

Pourquoi les labels sont-ils si importants ?

Parce qu’ils lient le controleur aux pods qu’il gere.

La reconciliation appliquee aux replicas

Le ReplicaSet illustre tres bien la reconciliation. On declare replicas: 3. Le controleur observe les pods correspondant au selecteur. S’il n’en trouve que deux, il en cree un. S’il en trouve quatre, il en supprime un. Le but n’est pas de se souvenir d’une commande passee, mais de maintenir un etat.

Cette logique est visible avec une experience simple: supprimer manuellement un pod gere par un ReplicaSet. Le pod disparait, puis un nouveau pod apparait avec un autre nom.

Experience a faire en lab

kubectl apply -f replicaset.yaml
kubectl get pods -l app=web
kubectl delete pod <un-pod-du-replicaset>
kubectl get pods -l app=web -w

La commande -w permet de regarder Kubernetes recreer un pod. C’est une demonstration concrete du role du controleur.

Pourquoi Deployment arrive ensuite

Le ReplicaSet maintient un nombre de pods, mais il ne gere pas confortablement toute la strategie de mise a jour applicative. Le Deployment ajoute une couche au-dessus: rollout, rollback, historique et creation de nouveaux ReplicaSets lors des changements d’image ou de template.

Pour comprendre Kubernetes, il est utile de voir ReplicaSet une fois. Pour travailler au quotidien, on manipulera surtout Deployment.

Selectors: attention au couplage

Le selecteur d’un ReplicaSet doit correspondre aux labels du template. S’il est trop large, il peut adopter des pods qui n’etaient pas prevus. S’il est trop restrictif ou incoherent, le controleur ne trouvera pas ses pods.

Erreurs frequentes

• Modifier les labels du template sans ajuster le selector.
• Croire que le ReplicaSet expose automatiquement l’application: il faut un Service pour cela.
• Utiliser directement ReplicaSet en production au lieu d’un Deployment.
• Supprimer un pod et s’etonner qu’il revienne.

A retenir

Le ReplicaSet n’est pas seulement un objet de plus. C’est le premier controleur qui montre vraiment la promesse Kubernetes: declarer un nombre attendu, puis laisser la plateforme corriger les ecarts.

Observer le lien entre ReplicaSet et pods

Les pods crees par un ReplicaSet ont des labels communs et un owner reference qui indique quel controleur les gere. On peut l’observer avec:

kubectl get pods -l app=web --show-labels
kubectl get pod <pod> -o yaml

Dans le YAML du pod, metadata.ownerReferences montre que le pod appartient au ReplicaSet. Cette information explique pourquoi la suppression manuelle du pod ne suffit pas a faire disparaitre durablement l’instance.

Modifier le nombre de replicas

Pour tester la reconciliation, on peut changer le nombre de replicas:

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

Le controleur ajuste progressivement la realite vers l’etat demande. Cette operation illustre la difference entre lancer une commande imperativement et declarer un etat voulu.

Pourquoi les selectors sont sensibles

Un selector est une frontiere de responsabilite. Si deux controleurs selectionnent les memes pods, le comportement devient difficile a comprendre. Kubernetes impose certaines validations, mais il reste possible de creer de la confusion avec des labels mal choisis.

Une convention simple aide beaucoup: utiliser des labels stables comme app, component, environment et eviter de reutiliser le meme couple de labels pour des workloads differents. Plus les labels sont propres, plus les Services, ReplicaSets et Deployments seront faciles a relire.

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 014 – Kubectl : les contextes.

Conclusion

Le ReplicaSet montre la logique de reconciliation de Kubernetes de facon concrete: maintenir un nombre attendu de pods. C’est une marche essentielle avant les Deployments.