## 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 : ```bash kubectl version --short ``` Sortie attendue (les versions peuvent différer) : ```text 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. ```bash kubectl config view --minify | grep namespace ``` Si la sortie n'est pas l'espace de noms attendu, basculez avec : ```bash kubectl config set-context --current --namespace=my-app ``` Maintenant, listez les ReplicaSets existants dans cet espace de noms : ```bash kubectl get replicasets ``` Exemple de sortie : ```text 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 : ```bash 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` : ```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 : ```bash 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 : ```bash kubectl scale replicaset test-rs --replicas=4 ``` Vérifiez que les nouveaux pods sont en cours d'exécution : ```bash 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 : ```bash 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 : ```bash 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 : ```bash 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 : ```bash kubectl describe pod ``` 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 : ```bash kubectl logs --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 : ```bash 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` : ```bash kubectl exec -it -- 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 : ```bash kubectl describe rs | 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 : ```bash kubectl logs --previous ``` Corrigez l'erreur de l'application, puis supprimez le pod pour forcer le ReplicaSet à en créer un nouveau : ```bash kubectl delete pod ``` 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 : ```bash kubectl get rs -o jsonpath='{.spec.selector}' && echo kubectl get rs -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 : ```bash kubectl get pods -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 ` 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 --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 ` 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 --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.