Concept de ReplicaSet (géré par le Déploiement)

Le besoin d'un gardien pour les Pods

Nous avons vu que le Déploiement a pour rôle principal de maintenir un nombre défini de Pods en cours d'exécution. Mais comment fait-il cela concrètement ? Quel est le mécanisme sous-jacent qui surveille activement les Pods et en crée ou supprime pour correspondre à l'état désiré ? La réponse se trouve dans un autre objet contrôleur de Kubernetes : le ReplicaSet.

Un ReplicaSet a un objectif simple mais crucial : garantir qu'un nombre spécifié de réplicas de Pods, basés sur un modèle (template) donné, sont en cours d'exécution à tout moment. C'est le moteur qui effectue le travail d'auto-réparation et de maintien du nombre de réplicas que nous avons attribué au Déploiement.

Historiquement, avant l'introduction des Déploiements, les ReplicaSets (et leur prédécesseur, le ReplicationController) étaient utilisés directement. Cependant, les ReplicaSets seuls ne fournissent pas de fonctionnalités de mise à jour ou de rollback. C'est pourquoi, dans la pratique moderne de Kubernetes, vous interagissez rarement directement avec les ReplicaSets ; ils sont considérés comme un détail d'implémentation géré par les Déploiements.

Déploiement et ReplicaSet : une collaboration essentielle

La relation entre un Déploiement et un ReplicaSet est celle d'un chef d'orchestre et d'un musicien spécialisé. Le Déploiement est le chef d'orchestre : il définit la stratégie globale, notamment comment gérer les mises à jour et les retours en arrière, et quel état final atteindre. Le ReplicaSet est le musicien : il exécute une tâche spécifique, celle de maintenir un nombre exact de Pods pour une configuration (template) particulière.

Lorsqu'un Déploiement est créé, il ne crée pas directement les Pods. A la place, il crée un ReplicaSet. Ce ReplicaSet hérite du nombre de réplicas (`replicas`), du sélecteur (`selector`) et du modèle de Pod (`template`) définis dans le Déploiement.

C'est ensuite ce ReplicaSet qui prend le relais pour créer les Pods nécessaires afin d'atteindre le nombre de réplicas souhaité. Le ReplicaSet surveille en permanence les Pods correspondant à son sélecteur et s'assure que leur nombre correspond à sa propre valeur `replicas`. Si un Pod disparaît, le ReplicaSet en crée un nouveau basé sur son `template`. Si le nombre de `replicas` du ReplicaSet est réduit, il supprime les Pods excédentaires.

Le Déploiement, quant à lui, surveille le ReplicaSet qu'il a créé et s'assure qu'il fait correctement son travail pour atteindre l'objectif global du Déploiement.

Gestion des mises à jour : le rôle des multiples ReplicaSets

La véritable puissance de cette collaboration apparaît lors des mises à jour d'applications. Supposons que vous modifiez le `template` du Pod dans votre Déploiement (par exemple, en changeant la version de l'image du conteneur) et que vous appliquez ce changement.

Le Déploiement ne modifie pas le ReplicaSet existant. Au lieu de cela, il crée un nouveau ReplicaSet basé sur le nouveau `template`, initialement avec un nombre de réplicas à zéro. Ensuite, selon la stratégie de mise à jour définie (par exemple, `RollingUpdate`), le Déploiement orchestre une transition contrôlée :

1. Il augmente progressivement le nombre de `replicas` du nouveau ReplicaSet (créant ainsi de nouveaux Pods avec la nouvelle version).
2. Simultanément, il diminue progressivement le nombre de `replicas` de l'ancien ReplicaSet (supprimant les anciens Pods).

Ce processus se poursuit jusqu'à ce que tous les anciens Pods soient remplacés par les nouveaux, et que le nouveau ReplicaSet gère le nombre total de `replicas` défini dans le Déploiement. L'ancien ReplicaSet est conservé (avec `replicas: 0`) pour permettre un éventuel retour en arrière (rollback).

Le Déploiement utilise donc les ReplicaSets comme des "instantanés" de chaque version de votre application. Chaque ReplicaSet gère les Pods d'une révision spécifique, et le Déploiement orchestre le passage de l'un à l'autre lors des mises à jour et des rollbacks.

Observer les ReplicaSets en action

Bien que vous ne les créiez généralement pas manuellement, vous pouvez observer les ReplicaSets gérés par vos Déploiements. La commande `kubectl get replicasets` (ou `kubectl get rs`) liste les ReplicaSets présents dans votre cluster.

kubectl get rs

# Sortie possible après la création ou la mise à jour d'un déploiement :
# NAME                          DESIRED   CURRENT   READY   AGE
# mon-app-deployment-6b86c57f45   3         3         3       10m 
# mon-app-deployment-7d99f4b8c6   0         0         0       5m  # <-- Ancien RS (après mise à jour)

Vous remarquerez souvent que les noms des ReplicaSets sont générés automatiquement en ajoutant un hash au nom du Déploiement parent (par exemple, `mon-app-deployment-6b86c57f45`). Cela permet de distinguer les différentes révisions.

Les colonnes `DESIRED`, `CURRENT`, et `READY` indiquent respectivement le nombre de Pods que le ReplicaSet souhaite avoir, le nombre actuel de Pods qu'il gère, et le nombre de ces Pods qui sont prêts à servir du trafic. En observant ces valeurs lors d'une mise à jour, vous pouvez voir le transfert progressif des Pods d'un ReplicaSet à l'autre.

En résumé, le ReplicaSet est le cheval de bataille qui assure la réplication des Pods. Le Déploiement est le gestionnaire intelligent qui utilise les ReplicaSets pour non seulement maintenir l'état désiré, mais aussi pour orchestrer des mises à jour et des retours en arrière fluides de vos applications.