## Introduction Le ReplicationController (RC) de Kubernetes garantit qu'un nombre spécifié de réplicas de pods sont en cours d'exécution à tout moment. Bien que les ReplicaSets et les Deployments l'aient largement remplacé, le ReplicationController reste un concept fondamental pour comprendre la réplication et l'auto-réparation des pods. Ce guide fournit des commandes pratiques, des exemples de configuration, des techniques de dépannage et des procédures de récupération pour les développeurs, les ingénieurs DevOps et les équipes de startup qui doivent exploiter des ReplicationControllers dans de vrais clusters. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets, vérifier les résultats et documenter les étapes de récupération si l'état attendu n'est pas atteint. Chaque section comprend des commandes concrètes, les sorties attendues, les signaux d'échec et les décisions de récupération. ## Inventaire de la version et de l'environnement Avant de travailler avec des ReplicationControllers, vérifiez la version de votre cluster et les ressources d'API disponibles. Les ReplicationControllers font partie du groupe d'API core/v1 et restent pris en charge dans toutes les versions actuelles de Kubernetes, bien qu'ils soient considérés comme hérités. ### Vérifier les versions du client et du serveur kubectl version --short La sortie attendue inclut les versions client et serveur : Client Version: v1.26.0 Server Version: v1.26.0 Si la version du serveur est plus ancienne que celle du client, les commandes peuvent échouer ; utilisez une version de kubectl correspondante. ### Vérifier la disponibilité de l'API ReplicationController kubectl api-resources | grep replicationcontrollers Sortie attendue : replicationcontrollers rc v1 true ReplicationController Si la ressource n'est pas listée, le cluster peut avoir un accès API restreint. Vérifiez les autorisations RBAC avec : kubectl auth can-i list replicationcontrollers Sortie attendue : yes . ### Confirmer les prérequis - Un cluster Kubernetes en cours d'exécution (minikube, kind, GKE, EKS, etc.). - kubectl installé et configuré avec l'accès au cluster. - Compréhension de base des pods et des étiquettes. Observation en lecture seule : commencez toujours par des commandes kubectl get pour comprendre l'état actuel avant d'apporter des modifications. ### Vérifications Kubernetes pratiques Exécutez ces commandes pour recueillir l'état initial : kubectl get pods -o wide kubectl get replicationcontrollers kubectl get nodes Enregistrez les sorties avec des horodatages pour une comparaison ultérieure : kubectl get replicationcontrollers -o yaml > rc-before.yaml date >> rc-before.yaml Test minimal : avant d'appliquer tout changement, assurez-vous de pouvoir créer un simple ReplicationController dans un espace de noms de test. Utilisez kubectl port-forward ou un type de service local pour vérifier le trafic avant de passer à un équilibreur de charge ou à une entrée. ## Chemin de configuration sécurisé Exploiter des ReplicationControllers en toute sécurité signifie apporter des modifications incrémentales et réversibles. Suivez ce chemin : ### Étape 1 : Inspecter l'état actuel Utilisez des commandes en lecture seule pour voir les ReplicationControllers existants : kubectl get replicationcontrollers --all-namespaces Exemple de sortie : NAMESPACE NAME DESIRED CURRENT READY AGE default nginx 3 3 3 5m ### Étape 2 : Comprendre le manifeste du ReplicationController Un YAML de base pour ReplicationController : apiVersion: v1 kind: ReplicationController metadata: name: nginx-rc spec: replicas: 3 selector: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80 Champs clés : - spec.replicas : nombre souhaité de pods. - spec.selector : doit correspondre aux étiquettes du modèle de pod. S'il est omis, il prend par défaut les étiquettes du modèle. - spec.template : modèle de pod utilisé pour créer de nouveaux pods. ### Étape 3 : Appliquer le manifeste avec vérification Créez le ReplicationController : kubectl apply -f nginx-rc.yaml Sortie attendue : replicationcontroller/nginx-rc created Vérifiez que les pods sont créés : kubectl get pods -l app=nginx Sortie attendue : NAME READY STATUS RESTARTS AGE nginx-rc-abcde 1/1 Running 0 10s nginx-rc-fghij 1/1 Running 0 10s nginx-rc-klmno 1/1 Running 0 10s ### Étape 4 : Apporter de petites modifications Pour mettre à l'échelle le ReplicationController, utilisez la commande kubectl scale : kubectl scale replicationcontroller nginx-rc --replicas=5 Sortie attendue : replicationcontroller/nginx-rc scaled Vérifiez les nouveaux pods : kubectl get rc nginx-rc Sortie : NAME DESIRED CURRENT READY AGE nginx-rc 5 5 5 10m ### Étape 5 : Vérifier le trafic localement Utilisez le transfert de port pour tester un pod : kubectl port-forward rc/nginx-rc 8080:80 Accédez ensuite à http://localhost:8080 dans un navigateur ou avec curl . Attendez-vous à la page d'accueil nginx. Contrôle du rayon d'impact : n'appliquez jamais de modifications directement en production sans les tester dans un espace de noms de bac à sable. Utilisez --dry-run=client pour valider les manifestes : kubectl apply -f nginx-rc.yaml --dry-run=client ## Vérification et diagnostics Après avoir appliqué des modifications, vérifiez l'état de santé du ReplicationController et diagnostiquez les problèmes. ### Commandes de vérification de base kubectl get rc nginx-rc kubectl describe rc nginx-rc La sortie de describe inclut les événements, le sélecteur et les statuts des pods. Recherchez les événements SuccessfulCreate et tout échec. Vérifiez le statut des pods en détail : kubectl get pods -l app=nginx -o wide Si un pod n'est pas en cours d'exécution, inspectez-le : kubectl describe pod Exemple de section d'échec : Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 2m default-scheduler 0/3 nodes are available: 3 Insufficient cpu. Cela indique des ressources insuffisantes. Récupération : réduisez l'échelle ou ajoutez des nœuds. ### Vérifier les journaux Pour un pod en cours d'exécution : kubectl logs Pour un pod qui a planté, vérifiez les journaux précédents : kubectl logs --previous Exemple de journal de boucle de crash : Error: unable to start application: config file not found Récupération : corrigez le chemin du fichier de configuration dans le modèle de pod. ### Vérifier le statut du ReplicationController via YAML kubectl get rc nginx-rc -o yaml Regardez status.replicas , status.readyReplicas et status.observedGeneration . Si les réplicas prêts sont inférieurs au nombre souhaité, le RC est en mauvaise santé. ### Diagnostics avancés - Vérifiez les événements dans l'espace de noms : kubectl get events --sort-by=.metadata.creationTimestamp - Surveillez les changements de pods en direct : kubectl get pods -l app=nginx --watch Question rapide 2 sur 2 Quel est le remplacement recommandé pour ReplicationController ? - ReplicaSet - Deployment - DaemonSet - StatefulSet

La méthode recommandée pour créer une application répliquée est d'utiliser un Deployment, qui à son tour utilise un ReplicaSet.

## Modes de défaillance et récupération Les ReplicationControllers peuvent échouer de différentes manières. Voici les modes de défaillance courants et comment les récupérer. ### Mode de défaillance 1 : Les pods ne sont pas créés Symptôme : kubectl get rc affiche desired=3 mais current=0. Diagnostic : kubectl describe rc nginx-rc Recherchez des événements comme : Warning FailedCreate ReplicationController Error creating: pods is forbidden: User cannot create resource pods in namespace default Cause : restrictions RBAC. Récupération : corrigez les autorisations RBAC ou utilisez un espace de noms avec un accès approprié. Vérifiez avec : kubectl auth can-i create pods Attendu : yes . ### Mode de défaillance 2 : Pods en CrashLoopBackOff Symptôme : les pods sont dans l'état CrashLoopBackOff . Diagnostic : kubectl get pods -l app=nginx kubectl logs --previous Exemple de journal : nginx: [emerg] unexpected end of file, expecting ";" in /etc/nginx/conf.d/default.conf:10 Cause : fichier de configuration mal configuré. Récupération : corrigez la configuration dans le modèle de pod, mettez à jour le manifeste du RC et appliquez. Supprimez les pods existants pour forcer la recréation : kubectl delete pod -l app=nginx Le RC les remplacera automatiquement. ### Mode de défaillance 3 : Le RC ne peut pas être mis à l'échelle Symptôme : kubectl scale échoue ou aucun pod n'est ajouté. Diagnostic : kubectl describe rc nginx-rc Recherchez des erreurs de quota de ressources : Warning FailedCreate ReplicationController Error creating: pods is forbidden: exceeded quota Cause : quota de ressources de l'espace de noms dépassé. Récupération : augmentez le quota ou réduisez les réplicas. Vérifiez le quota : kubectl get resourcequota ### Mode de défaillance 4 : Inadéquation du sélecteur Symptôme : le RC signale des réplicas souhaités mais aucun pod n'est sélectionné ; ou des pods supplémentaires sont sélectionnés. Diagnostic : comparez spec.selector dans le RC avec les étiquettes des pods : kubectl get rc nginx-rc -o jsonpath='{.spec.selector}' kubectl get pods -l app=nginx --show-labels Si les étiquettes ne correspondent pas, le RC ne gérera pas ces pods. Récupération : corrigez le sélecteur dans le manifeste et appliquez à nouveau. Notez que modifier le sélecteur est perturbateur ; envisagez de supprimer et de recréer le RC. ### Flux de travail général de récupération - Prenez un instantané avant les modifications : kubectl get rc nginx-rc -o yaml > rc-backup.yaml - Appliquez le correctif. - Vérifiez : kubectl get pods -l app=nginx - Si la récupération échoue, restaurez à partir de la sauvegarde : kubectl apply -f rc-backup.yaml ## Liste de contrôle des opérations Utilisez cette liste de contrôle pour les opérations quotidiennes sur les ReplicationControllers. ### Liste de contrôle avant modification - [ ] Confirmez la version du cluster et l'accès à l'API. - [ ] Inspectez le RC et les pods actuels : kubectl get rc,pods -l app= - [ ] Sauvegardez le manifeste actuel du RC : kubectl get rc -o yaml > backup-.yaml - [ ] Testez la modification en mode simulation : kubectl apply -f --dry-run=client ### Liste de contrôle d'exécution de la modification - [ ] Appliquez la modification : kubectl apply -f - [ ] Surveillez le déploiement (si mise à l'échelle) : kubectl rollout status rc/ # Remarque : rollout status fonctionne pour les Deployments, pas pour les RC ; utilisez get rc à la place Pour RC, utilisez : kubectl get rc -w - [ ] Vérifiez la disponibilité des pods : kubectl get pods -l - [ ] Vérifiez les journaux pour les erreurs : kubectl logs --tail=20 ### Liste de contrôle de vérification après modification - [ ] Confirmez que desired=current=ready : kubectl get rc - [ ] Testez le point de terminaison de l'application via le transfert de port ou le service. - [ ] Documentez la modification et tout comportement inattendu. ### Exemple pas à pas : mise à l'échelle et vérification # Mettre à l'échelle nginx-rc à 4 réplicas kubectl scale rc nginx-rc --replicas=4 # Surveiller la création des pods kubectl get pods -l app=nginx -w # Après que les pods sont prêts, vérifier kubectl get rc nginx-rc # Tester un pod kubectl port-forward rc/nginx-rc 8080:80 # curl localhost:8080 ## Conclusion Les commandes Kubernetes ReplicationController sont essentielles pour gérer la réplication des pods, même dans les environnements hérités. En suivant un chemin de configuration sécurisé, en vérifiant chaque modification et en ayant des plans de récupération pour les défaillances courantes, vous pouvez garantir une haute disponibilité et un dépannage rapide. Commencez toujours par des observations en lecture seule, limitez les modifications et documentez les étapes de récupération. Prochaines étapes : entraînez-vous à créer et à mettre à l'échelle un ReplicationController dans un cluster de test, expérimentez des scénarios de défaillance comme la suppression de pods et observez l'auto-réparation, puis migrez vers des Deployments pour des fonctionnalités plus avancées comme les mises à jour progressives. N'oubliez pas de passer en revue les dépendances telles que ReplicaSet, Deployment et Pod pour comprendre l'évolution de la réplication dans Kubernetes. Un flux de travail opérationnel fiable rend les défaillances visibles, protège les données sensibles, limite les modifications aux ressources prévues et définit la vérification de la récupération avant que les incidents ne forcent des décisions.