ReplicaSets : Assurer un nombre défini de réplicas de Pods (géré par Deployment)

Le garant du nombre : introduction au ReplicaSet

Dans notre exploration des Deployments, nous avons mentionné qu'ils s'appuient sur un autre objet pour gérer le nombre effectif de Pods : le ReplicaSet. Bien que vous interagissiez rarement directement avec les ReplicaSets lorsque vous utilisez des Deployments, comprendre leur rôle est essentiel pour saisir pleinement comment Kubernetes assure la scalabilité et l'auto-réparation de vos applications.

Le but fondamental d'un ReplicaSet est simple mais crucial : garantir qu'un nombre spécifié de réplicas de Pods (qui correspondent à un certain template) sont en cours d'exécution à tout moment. Si des Pods disparaissent ou sont supprimés, le ReplicaSet en crée de nouveaux. S'il y en a trop, il en supprime.

Il représente la brique de base de la gestion des réplicas et de la haute disponibilité pour les Pods identiques dans Kubernetes. C'est un contrôleur de workload, appliquant la boucle de réconciliation pour maintenir l'état désiré en termes de nombre d'instances.

Fonctionnement et structure d'un ReplicaSet

Comment un ReplicaSet accomplit-il sa mission ? Comme les autres contrôleurs, il utilise un sélecteur pour identifier les Pods qu'il doit gérer et un template pour savoir comment créer de nouveaux Pods si nécessaire.

• Sélecteur (`spec.selector`) : Définit les labels que les Pods doivent avoir pour être considérés comme gérés par ce ReplicaSet.
• Nombre de réplicas (`spec.replicas`) : Le nombre désiré de Pods qui doivent correspondre au sélecteur.
• Template de Pod (`spec.template`) : La spécification complète (metadata avec labels correspondants au sélecteur, et spec) utilisée pour créer de nouveaux Pods lorsque le nombre actuel est inférieur au nombre désiré.

La boucle de réconciliation du ReplicaSet compte en permanence combien de Pods correspondent à son sélecteur. Si ce nombre est différent de `spec.replicas`, il crée ou supprime des Pods (basés sur le `spec.template`) pour atteindre le compte cible. C'est ce mécanisme qui assure l'auto-réparation : si un Pod géré par le ReplicaSet est supprimé ou échoue, le compte diminue, et le contrôleur en crée un nouveau.

Voici à quoi ressemble un manifeste YAML pour un ReplicaSet :

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: mon-app-replicaset
  labels:
    app: mon-app
    tier: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      # Ces labels doivent correspondre à ceux du template ci-dessous
      tier: backend
      # Note: Le label 'app' n'est pas dans le sélecteur ici (mais pourrait l'être)
  template:
    metadata:
      labels:
        # Labels appliqués aux Pods créés par ce ReplicaSet
        tier: backend
        app: mon-app # Ce label n'est pas utilisé par le sélecteur du RS,
                     # mais pourrait être utilisé par un Service, par exemple.
    spec:
      containers:
      - name: backend-conteneur
        image: mon-backend-image:v1.1
        ports:
        - containerPort: 9000

Vous remarquerez la grande similarité avec la structure d'un Deployment, à l'exception notable de l'absence du champ `strategy`.

Pourquoi utiliser un Deployment plutôt qu'un ReplicaSet direct ?

Si un ReplicaSet garantit déjà le nombre de réplicas et l'auto-réparation, pourquoi avons-nous besoin des Deployments ? La réponse réside dans la gestion des mises à jour et des rollbacks. Un ReplicaSet est lié à une version spécifique du template de Pod. Si vous voulez mettre à jour l'image du conteneur ou une autre partie du template, vous devriez créer un nouveau ReplicaSet avec le nouveau template et orchestrer manuellement la transition (scaler l'ancien RS à 0, scaler le nouveau à N, ou essayer de faire une mise à jour progressive manuelle, ce qui est complexe).

Le Deployment automatise entièrement ce processus. Comme nous l'avons vu, lorsque vous mettez à jour le `template` d'un Deployment :

1. Il crée un nouveau ReplicaSet avec le nouveau template.
2. Il orchestre la montée en puissance du nouveau ReplicaSet et la descente en puissance de l'ancien, selon la stratégie de mise à jour choisie (RollingUpdate ou Recreate).
3. Il conserve les anciens ReplicaSets (selon `revisionHistoryLimit`) pour permettre des rollbacks faciles vers des états précédents.

Ainsi, le Deployment agit comme un gestionnaire intelligent *au-dessus* des ReplicaSets, ajoutant des fonctionnalités cruciales de gestion du cycle de vie déclaratif. C'est pourquoi il est fortement recommandé d'utiliser les Deployments pour gérer les applications stateless, et de considérer les ReplicaSets comme un détail d'implémentation géré par les Deployments.

Vous n'aurez besoin de manipuler directement un ReplicaSet que dans des cas très spécifiques ou si vous utilisez des outils qui n'ont pas encore adopté les Deployments (ce qui est rare aujourd'hui).

Avec `kubectl`, vous pouvez inspecter les ReplicaSets (`kubectl get rs`, `kubectl describe rs mon-app-replicaset-xxxxx`), mais la plupart du temps, vous interagirez avec l'objet Deployment parent.

Conclusion : la fondation silencieuse de la réplication

Le ReplicaSet est le moteur sous-jacent qui garantit qu'un nombre défini d'instances de vos Pods sont toujours disponibles dans Kubernetes. Il fournit les mécanismes essentiels de réplication et d'auto-réparation sur lesquels reposent des contrôleurs plus sophistiqués.

Bien qu'il soit généralement masqué par l'abstraction du Deployment pour les applications stateless, comprendre son rôle et son fonctionnement vous aide à mieux appréhender la magie derrière la robustesse et la scalabilité offertes par Kubernetes. C'est un exemple parfait de la manière dont Kubernetes construit des abstractions puissantes en composant des briques fondamentales plus simples.