Kubernetes ReplicationController : commandes de base avec exemples pratiques

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 <pod-name>

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 <pod-name>

Pour un pod qui a planté, vérifiez les journaux précédents :

kubectl logs <pod-name> --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

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 <pod-name> --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

1. Prenez un instantané avant les modifications :

kubectl get rc nginx-rc -o yaml > rc-backup.yaml

1. Appliquez le correctif.
2. Vérifiez :

kubectl get pods -l app=nginx

1. 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=<label>

• [ ] Sauvegardez le manifeste actuel du RC :

  kubectl get rc <name> -o yaml > backup-<name>.yaml

• [ ] Testez la modification en mode simulation :

  kubectl apply -f <manifest> --dry-run=client

Liste de contrôle d'exécution de la modification

• [ ] Appliquez la modification :

  kubectl apply -f <manifest>

• [ ] Surveillez le déploiement (si mise à l'échelle) :

  kubectl rollout status rc/<name>   # Remarque : rollout status fonctionne pour les Deployments, pas pour les RC ; utilisez get rc à la place

Pour RC, utilisez :

  kubectl get rc <name> -w

• [ ] Vérifiez la disponibilité des pods :

  kubectl get pods -l <selector>

• [ ] Vérifiez les journaux pour les erreurs :

  kubectl logs <pod-name> --tail=20

Liste de contrôle de vérification après modification

• [ ] Confirmez que desired=current=ready :

  kubectl get rc <name>

• [ ] 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.