Commandes Kubernetes ReplicaSet : guide pratique avec exemples

Introduction

Travailler avec les ReplicaSets Kubernetes commence souvent par un objectif simple : garantir qu'un nombre spécifié de réplicas de pods soit en cours d'exécution à tout moment. En pratique, vous passerez plus de temps à inspecter pourquoi les pods ne deviennent pas prêts qu'à créer des ReplicaSets. Les commandes de ce guide sont organisées pour vous faire passer de l'observation à un résultat vérifié, avec des valeurs par défaut sûres et des exemples concrets.

Cet article couvre les commandes kubectl essentielles pour la gestion des ReplicaSets. Il s'adresse aux développeurs, ingénieurs DevOps et équipes techniques de startups qui ont besoin d'une référence pratique. Chaque section inclut la commande, la sortie attendue, les signaux de défaillance courants et la décision de récupération adaptée à la situation.

Le principe directeur est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des variables d'environnement plutôt que des secrets, vérifier les résultats et documenter les chemins de récupération. Exécutez d'abord les commandes dans un espace de noms non productif si vous les essayez pour la première fois.

Inventaire des versions et de l'environnement

Avant d'exécuter toute commande ReplicaSet, confirmez la version de Kubernetes et l'environnement. Le comportement des ReplicaSets est resté stable à travers de nombreuses versions, mais les versions plus récentes ajoutent souvent des champs ou modifient les comportements par défaut. Vérifiez vos versions client et serveur avec :

kubectl version --short

Sortie attendue (les versions peuvent différer) :

Client Version: v1.27.3
Kustomize Version: v5.0.1
Server Version: v1.27.3

Une divergence entre client et serveur est généralement acceptable si elle est dans une version mineure près, mais pour le travail en production, gardez-les alignées. Ensuite, confirmez que vous êtes dans le bon espace de noms. Beaucoup d'erreurs surviennent parce qu'une commande s'exécute dans l'espace de noms par défaut alors que le ReplicaSet se trouve ailleurs.

kubectl config view --minify | grep namespace

Si la sortie n'est pas l'espace de noms attendu, basculez avec :

kubectl config set-context --current --namespace=my-app

Maintenant, listez les ReplicaSets existants dans cet espace de noms :

kubectl get replicasets

Exemple de sortie :

NAME       DESIRED   CURRENT   READY   AGE
frontend   3         3         3       2d
backend    2         2         1       5h

Dans cet exemple, le ReplicaSet backend n'est pas entièrement prêt. C'est un signal pour inspecter avant de faire des changements. Avant toute intervention, enregistrez l'état actuel avec un horodatage. Cela vous donne une base de référence pour la comparaison et le retour en arrière. Par exemple :

kubectl get replicasets -o yaml > replicasets-backup-$(date +%Y%m%d-%H%M%S).yaml

Stockez ce fichier hors du cluster. Il vous aidera à restaurer le ReplicaSet si un changement ultérieur cause des problèmes.

Chemin de configuration sûr

Modifier un ReplicaSet doit être délibéré. Utilisez toujours une commande impérative pour mettre à jour un objet vivant, ou appliquez un manifeste modifié après avoir examiné le diff. Ne modifiez jamais un ReplicaSet directement sans sauvegarde.

La façon la plus sûre d'expérimenter est de faire un petit test local. Créez un manifeste nommé test-rs.yaml :

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: test-rs
  labels:
    app: guestbook
    tier: frontend
spec:
  replicas: 2
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

Appliquez-le et regardez le ReplicaSet créer des pods :

kubectl apply -f test-rs.yaml
kubectl get rs test-rs -w

Utilisez Ctrl+C pour arrêter de surveiller après que le nombre désiré de réplicas apparaisse. Si les pods ne deviennent pas prêts, inspectez-les avec kubectl describe pods -l tier=frontend.

Mettre à l'échelle un ReplicaSet est un changement de configuration courant. Vous pouvez le faire de manière impérative :

kubectl scale replicaset test-rs --replicas=4

Vérifiez que les nouveaux pods sont en cours d'exécution :

kubectl get rs test-rs
kubectl get pods -l tier=frontend

Alternativement, modifiez le manifeste, changez replicas: 2 en replicas: 4, et exécutez à nouveau kubectl apply -f test-rs.yaml. L'approche déclarative garde votre fichier comme source de vérité.

Pour un test local rapide de connectivité, utilisez le transfert de port vers un pod géré par le ReplicaSet :

kubectl port-forward pod/test-rs-xxxxx 8080:80

Remplacez test-rs-xxxxx par un nom de pod réel obtenu avec kubectl get pods -l tier=frontend. Ensuite, ouvrez http://localhost:8080 dans un navigateur. Cela évite d'exposer un service extérieurement pendant que vous validez le pod.

Vérification et diagnostics

Diagnostiquer les problèmes de ReplicaSet nécessite une approche systématique. Commencez par le statut du ReplicaSet, puis creusez dans les pods et les événements.

Obtenez des informations détaillées sur un ReplicaSet :

kubectl describe rs test-rs

Cherchez les événements en bas. Ils indiquent souvent des problèmes comme des erreurs de tirage d'image ou des ressources insuffisantes.

Vérifiez les pods appartenant au ReplicaSet :

kubectl get pods -l tier=frontend -o wide

L'option -o wide ajoute des informations sur le nœud et l'IP, ce qui aide à identifier les problèmes de planification.

Pour un pod qui n'est pas prêt, décrivez-le :

kubectl describe pod <pod-name>

Les raisons d'échec courantes incluent ImagePullBackOff, CrashLoopBackOff, Pending en raison d'absence de nœuds disponibles, ou FailedScheduling à cause de limites de ressources.

Affichez les journaux d'un conteneur qui plante :

kubectl logs <pod-name> --previous

L'option --previous montre les journaux de l'instance de conteneur précédente, ce qui est crucial pour les boucles de crash.

Si le ReplicaSet est créé par un déploiement, vérifiez aussi le statut du déploiement :

kubectl rollout status deployment/my-deployment

Cette commande attend que le déploiement se termine ou signale un échec.

Une sonde de préparation rapide peut être testée manuellement avec kubectl exec :

kubectl exec -it <pod-name> -- curl localhost:80/healthz

Remplacez /healthz par votre point de terminaison de santé réel. Si la commande échoue, la sonde de préparation échouera également.

Modes de défaillance et récupération

Les ReplicaSets échouent pour des raisons prévisibles. Reconnaître ces schémas accélère la récupération.

Pods bloqués à l'état Pending. Indique généralement un manque de CPU ou de mémoire, ou aucun nœud correspondant aux sélecteurs de nœuds. Vérifiez les événements :

kubectl describe rs <rs-name> | grep -A10 Events

Si les ressources sont le problème, réduisez les demandes ou ajoutez des nœuds. Si les sélecteurs de nœuds sont erronés, corrigez le sélecteur dans le modèle de pod.

Pods en boucle de crash (CrashLoopBackOff). L'application sort immédiatement après le démarrage. Inspectez les journaux :

kubectl logs <pod-name> --previous

Corrigez l'erreur de l'application, puis supprimez le pod pour forcer le ReplicaSet à en créer un nouveau :

kubectl delete pod <pod-name>

Le contrôleur ReplicaSet le remplacera automatiquement.

Le ReplicaSet ne crée pas de pods. Cela peut arriver si le sélecteur ne correspond pas aux étiquettes du modèle de pod. Le ReplicaSet affichera 0 désiré mais aucune erreur. Validez le sélecteur :

kubectl get rs <rs-name> -o jsonpath='{.spec.selector}' && echo
kubectl get rs <rs-name> -o jsonpath='{.spec.template.metadata.labels}' && echo

S'ils ne correspondent pas, modifiez le ReplicaSet pour les aligner. Notez que changer le sélecteur est restreint dans les versions Kubernetes plus récentes ; vous devrez peut-être supprimer et recréer le ReplicaSet.

Erreurs de tirage d'image. Si le nom ou l'étiquette de l'image est incorrect, ou si les informations d'identification du registre sont manquantes, les pods affichent ImagePullBackOff. Confirmez que l'image existe et que le registre est accessible. Pour les registres privés, assurez-vous que le pod a un secret de tirage d'image :

kubectl get pods <pod-name> -o jsonpath='{.spec.imagePullSecrets}' && echo

Si vide, ajoutez un secret de tirage d'image au modèle de pod.

La récupération implique toujours de corriger la cause racine, puis de supprimer le pod ou de mettre à jour le ReplicaSet.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour les opérations de routine sur les ReplicaSets. Attribuez un seul propriétaire à chaque élément si vous travaillez en équipe, et révisez la liste mensuellement ou après tout incident.

[ ] Alignement des versions : kubectl version montre un écart d'au plus une version mineure entre client et serveur. Propriétaire : responsable DevOps.
[ ] Vérification de l'espace de noms : kubectl config get-contexts affiche le bon espace de noms courant. Propriétaire : opérateur de garde.
[ ] État actuel enregistré : kubectl get rs -o yaml > backup-rs-$(date +%F).yaml. Propriétaire : opérateur de garde.
[ ] Statut du ReplicaSet vérifié : kubectl get rs montre les compteurs désiré, courant et prêt. Propriétaire : propriétaire de l'application.
[ ] Pods sains : kubectl get pods -l <selector> montre tous les pods en cours d'exécution et prêts. Propriétaire : propriétaire de l'application.
[ ] Journaux examinés pour les erreurs : kubectl logs <pod> --tail=50 pour chaque pod. Propriétaire : développeur responsable du service.
[ ] Opération de mise à l'échelle vérifiée : Après mise à l'échelle, kubectl get rs <name> confirme le nouveau nombre de réplicas. Propriétaire : opérateur de garde.
[ ] Plan de retour en arrière documenté : Le YAML précédent du ReplicaSet est stocké et accessible. Propriétaire : responsable DevOps.
[ ] Événements vérifiés pour les avertissements : kubectl get events --sort-by=.metadata.creationTimestamp | tail -20. Propriétaire : opérateur de garde.

Parcourez cette liste avant et après tout changement de ReplicaSet. La cohérence prévient les surprises.

Pièges courants et comment les éviter

La gestion des ReplicaSets comporte plusieurs erreurs récurrentes. Les comprendre fait gagner du temps.

Piège 1 : Utiliser directement un ReplicaSet au lieu d'un déploiement. Les ReplicaSets ne prennent pas en charge les mises à jour progressives. Si vous devez mettre à jour le modèle de pod, vous devez supprimer manuellement les pods ou créer un nouveau ReplicaSet. Utilisez un déploiement pour les applications sans état ; il gère un ReplicaSet pour vous.

Piège 2 : Confondre étiquettes et sélecteurs. Le sélecteur du ReplicaSet doit correspondre exactement aux étiquettes du modèle de pod. Une non-correspondance entraîne l'absence de création de pods, ou le ReplicaSet adopte des pods qu'il ne possède pas. Vérifiez toujours avec kubectl get rs -o yaml.

Piège 3 : Ignorer la préparation des pods. Un pod peut être en cours d'exécution mais pas prêt, et le ReplicaSet le compte comme prêt seulement s'il passe les sondes de préparation. Si vos pods ne deviennent jamais prêts, le ReplicaSet augmentera sans fin (si vous utilisez un autoscaler horizontal de pods). Définissez des sondes de préparation qui reflètent la préparation réelle du service.

Piège 4 : Supprimer un ReplicaSet avant de supprimer ses pods. Si vous supprimez un ReplicaSet, ses pods ne sont pas automatiquement supprimés sauf si vous utilisez --cascade=true (la valeur par défaut dans les kubectl récents). Sinon, des pods orphelins restent. Utilisez kubectl delete rs <name> --cascade=orphan seulement si vous avez l'intention de garder les pods et de les adopter plus tard.

Piège 5 : Ne pas définir les demandes et limites de ressources. Sans demandes, le planificateur peut placer trop de pods sur un nœud, provoquant une famine de CPU ou des arrêts OOM. Définissez toujours les demandes et limites dans le modèle de pod.

Piège 6 : Oublier de mettre à jour l'étiquette d'image du ReplicaSet. Si vous mettez à jour l'image dans le modèle de pod mais ne déclenchez pas un déploiement, les pods existants restent sur l'ancienne image. Avec un déploiement, utilisez kubectl set image, mais avec un ReplicaSet, vous devez supprimer les pods manuellement ou utiliser un déploiement.

Évitez ces pièges en suivant les étapes de vérification de chaque section et en gardant la liste de contrôle des opérations à portée de main.

Conclusion

Les commandes Kubernetes ReplicaSet sont simples, mais une opération sûre exige de l'attention aux détails. Les commandes de ce guide fournissent une manière structurée d'observer, de diagnostiquer et de récupérer des problèmes courants. Rappelez-vous de toujours sauvegarder l'état actuel, de changer une chose à la fois et de vérifier après chaque changement.

Comme prochaine étape, choisissez une vérification à faible risque dans la liste de contrôle des opérations. Exécutez-la dans un espace de noms de test, enregistrez le résultat et comparez avec la sortie attendue. Ensuite, étendez votre pratique à un déploiement, qui est la méthode recommandée pour gérer les ReplicaSets pour les charges de travail sans état.

Un flux de travail fiable rend la défaillance visible, protège les valeurs sensibles, limite les changements à la ressource prévue et définit les étapes de récupération avant qu'un incident ne force la décision. Utilisez ces commandes quotidiennement et révisez-les avec votre équipe pour bâtir une confiance opérationnelle.