Les RéplicaSets Kubernetes
Mise à jour :
Dans Kubernetes, un Pod est l’unité de base pour exécuter une application. Cependant, un Pod seul n’est pas résilience : s’il tombe en panne, il ne sera pas automatiquement recréé.
Comment apporter de la résilience à un Pod ?
C’est là qu’intervient le ReplicaSet, une ressource Kubernetes qui garantit qu’un nombre défini de Pods est toujours en cours d’exécution. Si un Pod disparaît, le ReplicaSet le recrée automatiquement pour maintenir la disponibilité de l’application.
Création d’un ReplicaSet
Un ReplicaSet est une ressource Kubernetes qui assure qu’un nombre défini de Pods identiques est toujours en cours d’exécution. Si un Pod est supprimé ou tombe en panne, le ReplicaSet le remplace automatiquement.
Un ReplicaSet est défini par :
replicas
: le nombre de Pods à maintenir.selector
: une règle permettant d’identifier les Pods gérés.template
: le modèle de Pod utilisé pour créer de nouveaux Pods si nécessaire.
Définition d’un ReplicaSet en YAML
A partir de maintenant, nous allons créer principalement les ressources en utilisant des manifests écrits en YAML. Je vous invite donc à consulter mon guide sur comment écrire des manifests Kuberntes.
Voici un exemple de ReplicaSet qui exécute une application simple basée sur
hashicorp/http-echo
, un serveur HTTP minimaliste qui affiche un message
personnalisé.
apiVersion: apps/v1kind: ReplicaSetmetadata: name: echo-replicasetspec: replicas: 3 selector: matchLabels: app: echo template: metadata: labels: app: echo spec: containers: - name: echo-container image: hashicorp/http-echo:0.2.3 args: - "-text=Hello from ReplicaSet" ports: - containerPort: 5678
Explication des principaux champs :
replicas: 3
→ Kubernetes maintiendra toujours 3 Pods en fonctionnement.selector.matchLabels
→ Le ReplicaSet sélectionne les Pods ayant le labelapp: echo
.template.spec.containers
→ Spécifie le modèle du Pod :image: hashicorp/http-echo:0.2.3
→ L’image utilisée.args: ["-text=Hello from ReplicaSet"]
→ Configure le message retourné.ports.containerPort: 5678
→ Définit le port d’écoute de l’application.
Déployer le ReplicaSet
Appliquez le fichier YAML avec la commande :
kubectl apply -f replicaset.yaml
Vérifiez que le ReplicaSet est bien créé :
NAME DESIRED CURRENT READY AGEecho-replicaset 3 3 3 92s```
Vérifier les Pods créés
Le ReplicaSet a généré 3 Pods, comme défini dans replicas: 3
. Vérifiez-les
avec :
kubectl get pods -l app=echo
NAME READY STATUS RESTARTS AGEecho-replicaset-6j6kc 1/1 Running 0 2mecho-replicaset-npdh6 1/1 Running 0 2mecho-replicaset-wt4wl 1/1 Running 0 2m
Ici on demande à Kubernetes de nous lister les Pods ayant le label app: echo
.
Chaque Pod a un nom unique mais partage le même modèle défini dans le
ReplicaSet.
Supprimer un Pod et observer le ReplicaSet en action
L’intérêt d’un ReplicaSet est d’assurer la haute disponibilité. Si un Pod disparaît, Kubernetes en recrée un automatiquement.
Testez cela en supprimant un des Pods :
kubectl delete pod echo-replicaset-bd8fj
Vérifiez immédiatement si un nouveau Pod est créé :
kubectl get pods -l app=echo -w
Un nouveau Pod avec un nom différent apparaîtra pour remplacer le Pod supprimé et maintenir le nombre de réplicas défini.
kubectl get podNAME READY STATUS RESTARTS AGEecho-replicaset-mj9wl 1/1 Running 0 41secho-replicaset-npdh6 1/1 Running 0 6m21secho-replicaset-wt4wl 1/1 Running 0 6m21s
Vous remarquerez que le Pod supprimé n’est plus présent et qu’un nouveau Pod a été créé pour le remplacer. Il suffit de vérifier l’age pour voir le nouveau Pod.
Gestion des ReplicaSets
Une fois un ReplicaSet déployé, il est essentiel de savoir le superviser, le modifier et le supprimer correctement. Ce chapitre couvre les principales opérations de gestion d’un ReplicaSet Kubernetes.
Modifier le nombre de réplicas (Scaling)
Un ReplicaSet permet de faire évoluer dynamiquement le nombre de Pods en fonction des besoins en charge.
Modifier le scaling avec kubectl scale
:
kubectl scale rs echo-replicaset --replicas=5
Vérifiez les nouveaux Pods :
kubectl get pods -l app=echoNAME READY STATUS RESTARTS AGEecho-replicaset-8jqrr 1/1 Running 0 6secho-replicaset-mj9wl 1/1 Running 0 3m30secho-replicaset-npdh6 1/1 Running 0 9m10secho-replicaset-vdmb5 1/1 Running 0 6secho-replicaset-wt4wl 1/1 Running 0 9m10s
Kubernetes a ajouté 2 nouveaux Pods pour atteindre replicas: 5
.
Modifier le scaling en éditant le fichier YAML :
Vous pouvez aussi modifier directement le fichier YAML du ReplicaSet :
spec: replicas: 4
Puis appliquer la mise à jour :
kubectl apply -f replicaset.yaml
NAME READY STATUS RESTARTS AGEecho-replicaset-8jqrr 1/1 Running 0 47secho-replicaset-mj9wl 1/1 Running 0 4m11secho-replicaset-npdh6 1/1 Running 0 9m51secho-replicaset-vdmb5 1/1 Terminating 0 47secho-replicaset-wt4wl 1/1 Running 0 9m51s
Kubernetes à détruit un Pod pour atteindre replicas: 4
.
Si vous modifiez l’image du conteneur dans le fichier YAML et appliquez la mise à jour :
containers: - name: echo-container image: hashicorp/http-echo:1.0.0 # Nouvelle version de l'image
Puis :
kubectl apply -f replicaset.yaml
Les anciens Pods ne seront pas mis à jour, car le ReplicaSet ne remplace pas les Pods existants.
Solution recommandée : Utiliser un Deployment à la place d’un ReplicaSet, qui gère les mises à jour sans interruption. Ce point sera abordé dans le guide suivant sur les deployments.
Debug des ReplicaSets
Un ReplicaSet garantit qu’un nombre défini de Pods est toujours en cours
d’exécution. Cependant, il peut arriver que des Pods ne se lancent pas
correctement, restent bloqués en Pending
, ou que le ReplicaSet ne crée pas le
bon nombre de réplicas. Ce chapitre détaille les méthodes de diagnostic et de
résolution des problèmes courants.
Vérifier l’état du ReplicaSet
La première étape consiste à vérifier si le ReplicaSet fonctionne correctement et maintient le bon nombre de Pods.
kubectl get rs
NAME DESIRED CURRENT READY AGEecho-replicaset 3 1 1 5m
Problème détecté :
- DESIRED (3) ≠ CURRENT (1) → Le ReplicaSet devrait exécuter 3 Pods, mais un seul est actif.
- READY (1) → Seul 1 Pod est prêt.
Cela indique que Kubernetes ne parvient pas à créer tous les Pods nécessaires.
Vérifier les Pods associés au ReplicaSet
Listez les Pods gérés par le ReplicaSet :
kubectl get pods -l app=echo
Si des Pods sont en erreur (CrashLoopBackOff
, Pending
), affichez les détails
d’un Pod problématique :
kubectl describe pod <nom-du-pod>
Cas fréquents :
- *Pod bloqué en
Pending
:
Exemple de sortie :
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 30s (x5) default-scheduler 0/3 nodes are available: insufficient memory.
Cause probable : Pas assez de ressources disponibles sur les nœuds. Solution : Vérifiez l’état des nœuds et libérez des ressources.
kubectl get nodes -o wide
Si un nœud est en erreur (NotReady
), il se peut qu’il soit en panne.
Analyser les logs d’un Pod défaillant
Si un Pod se lance mais ne fonctionne pas correctement (CrashLoopBackOff
),
consultez ses logs :
kubectl logs <nom-du-pod>
Missing -text option!
Cause probable : L’application attend un argument manquant.
Solution : Vérifiez que l’application est bien configurée avec l’option
-text
dans args
.
containers: - name: echo-container image: hashicorp/http-echo:1.0.0 args: - "-text=Hello from ReplicaSet"
Appliquez la correction :
kubectl apply -f replicaset.yamlkubectl rollout restart rs echo-replicaset
Forcer la recréation d’un ReplicaSet
Si vos problèmes persistent, essayez de supprimer le ReplicaSet et le recréer :
kubectl delete rs echo-replicasetkubectl apply -f replicaset.yaml
Vérifiez à nouveau que les Pods sont bien recréés :
kubectl get pods -l app=echo
Conclusion
Les ReplicaSets sont des ressources Kubernetes essentielles pour garantir la haute disponibilité des applications. Ils assurent qu’un nombre défini de Pods est toujours en cours d’exécution, et recréent automatiquement les Pods en cas de panne. Mais ils ne gèrent pas les mises à jour des Pods. Pour cela, il est recommandé d’utiliser un Deployment.