Ingénierie du Chaos Avec Litmus : Un Projet Incubé par le CNCF

Énoncé du problème: Assurer la résilience d’une plateforme de commerce électronique basée sur des microservices.

La résilience du système est une exigence clé pour les plateformes de commerce électronique lors des opérations de mise à l’échelle afin de maintenir les services opérationnels et offrir une excellence de performance aux utilisateurs. Nous avons développé une plateforme d’architecture de microservices qui rencontre des pannes systématiques lorsqu’elle est confrontée à des événements de trafic intense. Les problèmes liés à la disponibilité de services réduite ainsi qu’à l’impact sur les revenus surviennent principalement en raison des plantages des pods Kubernetes, de l’épuisement des ressources et des perturbations réseau qui surviennent lors des périodes de shopping intenses.

L’organisation prévoit d’utiliser le projet Litmus, incubé par le CNCF, pour réaliser des évaluations et des améliorations de la résilience de la plateforme. Nos points faibles du système deviennent plus clairs lorsque nous effectuons des tests de défaillance simulés à l’aide de Litmus, ce qui nous permet de déclencher des situations de défaillance du monde réel telles que des événements de terminaison de pod, des retards réseau et des limites d’utilisation des ressources. Les expériences nous permettent de valider les systèmes d’automatisation de la scalabilité tout en testant les procédures de reprise après sinistre et en maximisant les paramètres de Kubernetes vers une fiabilité totale du système.

Le système crée une base solide pour faire face aux situations de défaillance et distribuer en toute sécurité les périodes de trafic intense sans détériorer la qualité de l’expérience utilisateur. L’ingénierie du chaos appliquée de manière proactive à notre infrastructure permet une meilleure réduction des risques et une observabilité accrue, ce qui nous permet de développer des méthodes de récupération automatisées qui améliorent la résilience de notre plateforme de commerce électronique face à toutes les conditions opérationnelles.

Mise en place de l’environnement d’expérimentation du chaos

Installer LitmusChaos dans votre cluster Kubernetes:

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/

helm repo update

helm install litmus litmuschaos/litmus

Vérifier l’installation:

kubectl get pods -n litmus

Remarque : Assurez-vous que votre cluster est prêt pour les expériences de chaos.

Définir l’expérience de chaos

Créer un fichier YAML ChaosExperiment pour simuler un scénario de suppression de pod.

Exemple (pod-delete.yaml) :

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosExperiment

metadata:

  name: pod-delete

  namespace: litmus

spec:

  definition:

    scope: Namespaced

    permissions:

      - apiGroups: ["*"]

        resources: ["*"]

        verbs: ["*"]

    image: "litmuschaos/go-runner:latest"

    args:

      - -c

      - ./experiments/generic/pod_delete/pod_delete.test

    command:

      - /bin/bash

Installer ChaosOperator et Configurer le compte de service

Déployer ChaosOperator pour gérer les expériences :

kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-operator/cluster-k8s.yml

Remarque : Créez un ServiceAccount pour accorder les autorisations nécessaires.

Injecter le Chaos dans l’application cible

Étiqueter l’espace de noms de l’application pour le chaos :

kubectl label namespace <target-namespace> litmuschaos.io/chaos=enabled

Déployer un ChaosEngine pour déclencher l’expérience :

Exemple (chaosengine.yaml) :

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosEngine

metadata:

  name: pod-delete-engine

  namespace: <target-namespace>

spec:

  appinfo:

    appns: '<target-namespace>'

    applabel: 'app=<your-app-label>'

    appkind: 'deployment'

  chaosServiceAccount: litmus-admin

  monitoring: false

  experiments:

    - name: pod-delete

Appliquer le ChaosEngine :

kubectl apply -f chaosengine.yaml

Surveiller l’expérience

Visualiser l’avancement :

kubectl describe chaosengine pod-delete-engine -n <target-namespace>

Vérifier l’état des pods de chaos :

kubectl get pods -n <target-namespace>

Analyser les résultats

Après l’expérience, examiner les journaux et les métriques pour déterminer si l’application s’est récupérée automatiquement ou a échoué sous stress.

Voici quelques métriques à surveiller :

• Temps de réponse de l’application
• Taux d’erreur pendant et après l’expérience
• Temps nécessaire aux pods pour récupérer

Solution

Cause racine identifiée : Pendant les périodes de forte affluence, les pods ont échoué en raison d’un nombre insuffisant de répliques dans le déploiement et de limites de ressources inappropriées.

Correctifs appliqués :

• Augmentation du nombre de répliques dans le déploiement pour gérer un trafic plus élevé
• A configuré des demandes et des limites de ressources appropriées pour le CPU et la mémoire dans la spécification du pod
• Implémenté un ajusteur de Pod Horizontal (HPA) pour gérer dynamiquement les pics de trafic

Conclusion

En utilisant LitmusChaos pour simuler des échecs de pods, nous avons identifié des faiblesses clés dans le déploiement Kubernetes de la plateforme de commerce électronique. L’expérience du chaos a démontré que la résilience peut être considérablement améliorée avec des ajustements d’échelle et d’allocation de ressources. L’ingénierie du chaos a permis un durcissement proactif du système, entraînant une meilleure disponibilité et satisfaction client.