ReplicationControllers

Les Replication Controllers (Contrôleurs de Réplication) ont été remplacés par les ReplicaSets et les Deployments dans Kubernetes, car ils offrent une gestion plus avancée des réplicas et des mises à jour d'applications.

Un schéma simplifié d'un Replication Controller dans Kubernetes peut vous aider à visualiser ses composants clés :

• Le "Replication Controller" est la ressource de niveau supérieur qui spécifie le nombre de réplicas désirés et le sélecteur pour les pods qu'il gère.

• Les "Pods" sont créés et maintenus par le "Replication Controller." Ils sont les instances individuelles de l'application. Chaque pod peut contenir un ou plusieurs conteneurs. Dans cet exemple, chaque pod contient un conteneur nommé "mon-conteneur" utilisant l'image "mon-image."

Le "Replication Controller" garantit que le nombre de réplicas spécifié est maintenu en permanence. Si un pod échoue ou doit être mis à jour, le "Replication Controller" prend en charge la création de nouveaux pods pour remplacer ceux qui sont défectueux ou obsolètes.

Ce schéma illustre un contrôleur de réplication simple avec trois réplicas de l'application "mon-app." Les "Pods" sont les unités d'exécution réelles de l'application, et le "Replication Controller" gère la réplication et la redondance pour maintenir le nombre spécifié de réplicas en cours d'exécution.

Exemple : Création d'un Replication Controller en utilisant un fichier YAML

apiVersion: v1
kind: ReplicationController
metadata:
  name: web-controller
spec:
  replicas: 3
  selector:
    app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx-container
        image: nginx:latest
---
apiVersion: v1
kind: Service
metadata:
  name: web-rc
spec:
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: NodePort  # nodePort: 30007

Pour créer le Replication Controller à partir de ce fichier YAML, utilisez la commande suivante :

kubectl apply -f rc/replication-controller.yaml

 

Quelques commandes associées

kubectl get rc
kubectl get replicationcontrollers
kubectl describe replicationcontrollers/web-controller
kubectl get replicationcontroller
kubectl get pods
kubectl delete pod web-controller-XXXXX
kubectl get pods
kubectl scale rc web-controller --replicas=5
kubectl get pods

 

---

Notez que ces exemples utilisent toujours les Replication Controllers, mais dans la pratique, il est recommandé d'utiliser les ReplicaSets ou les Deployments pour gérer des réplicas d'applications dans Kubernetes, car ils offrent plus de fonctionnalités et de flexibilité.

---

 

C'est d'utiliser les Deployments et ReplicaSets à la place des ReplicationControllers, parcequ'ils offrent davantage de fonctionnalités et de flexibilité. Voici les principales différences et avantages :

1. Fonctionnalités de Rolling Update et Rollback

• Deployments permettent de déployer des mises à jour progressives avec des rolling updates. Cela signifie que lorsque vous mettez à jour une application (par exemple, en changeant d'image Docker), les pods sont mis à jour progressivement, en limitant les interruptions.
• Rollback : en cas de problème, Deployments facilitent le retour à une version antérieure. Vous pouvez rapidement annuler une mise à jour pour restaurer une version fonctionnelle.

ReplicationControllers ne supporte pas ces fonctionnalités, ce qui signifie que toute mise à jour nécessite la suppression manuelle et la recréation des pods, entraînant souvent des interruptions de service.

2. Gestions avancée des Réplicas avec ReplicaSet

• ReplicaSets sont une évolution des ReplicationControllers et permettent de gérer les réplicas de pods de manière similaire. Cependant, ils intègrent une syntaxe plus flexible pour les sélecteurs de labels, ce qui rend leur utilisation plus intuitive et compatible avec les Deployments.
• Deployments utilisent des ReplicaSets en interne pour gérer les réplicas, combinant la gestion des mises à jour, des réplicas et des versions en un seul objet plus facile à manipuler.

3. Automatisation et Simplicité

• Les Deployments permettent de déclarer tout le cycle de vie d’une application en une seule ressource, ce qui simplifie l'automatisation et la gestion de l'infrastructure.
• Grâce aux Deployments, Kubernetes peut automatiquement surveiller l'état souhaité de l'application et prendre des actions correctives si le nombre de réplicas n’est pas respecté, ce qui n'est pas aussi flexible avec les ReplicationControllers.

4. Observabilité et Historique des Révisions

• Deployments maintiennent un historique des révisions, ce qui facilite le suivi des changements appliqués aux applications. Ce journal d'historique est essentiel pour l'audit et la gestion du cycle de vie des applications en production.
• ReplicationControllers n'ont pas de gestion d'historique ou de révisions, rendant la traçabilité et le débogage des applications plus compliqués.

5. Plus Grande Adoption et Développement Continu

• Les Deployments et ReplicaSets sont aujourd'hui des standards de facto dans Kubernetes. Leurs fonctionnalités continuent d'évoluer avec de nouvelles versions de Kubernetes, tandis que les ReplicationControllers sont progressivement dépréciés.
• La communauté Kubernetes recommande d'utiliser les Deployments pour la plupart des cas d'utilisation, ce qui garantit un meilleur support et des pratiques à jour.