Chaos Engineering Mit Litmus: Ein CNCF-Inkubationsprojekt

Problemstellung: Gewährleistung der Resilienz einer mikroservicesbasierten E-Commerce-Plattform.

Die Systemresilienz ist das zentrale Anliegen für E-Commerce-Plattformen während Skalierungsoperationen, um die Dienste betriebsbereit zu halten und eine hervorragende Leistung für die Nutzer zu gewährleisten. Wir haben eine Plattform mit einer Mikroservices-Architektur entwickelt, die sporadische Systemausfälle bei hohem Verkehrsaufkommen erlebt. Die Probleme mit der verminderten Serviceverfügbarkeit und den Auswirkungen auf den Umsatz treten hauptsächlich aufgrund von Kubernetes-Pod-Abstürzen sowie Ressourcenerschöpfung und Netzwerkausfällen auf, die in Spitzenverkaufszeiten auftreten.

Die Organisation plant, das CNCF-inkubierte Projekt Litmus zu nutzen, um Bewertungen und Resilienzverbesserungen der Plattform durchzuführen. Unsere Schwachstellen im System werden klarer, wenn wir simulierte Ausfalltests mit Litmus durchführen, das es uns ermöglicht, reale Ausfallsituationen wie Pod-Beendigungsereignisse, Netzwerkverzögerungen und Ressourcenverbrauchsgrenzen auszulösen. Die Experimente erlauben es uns, die Automatisierungssysteme zur Skalierbarkeit zu validieren, während wir die Verfahren zur Notfallwiederherstellung testen und die Kubernetes-Einstellungen maximieren, um die Gesamtsystemzuverlässigkeit zu gewährleisten.

Das System schafft eine solide Grundlage, um Ausfallsituationen zu bewältigen und geschäftige Verkehrszeiten sicher zu verteilen, ohne die Qualität der Benutzererfahrung zu beeinträchtigen. Die proaktive Anwendung von Chaos Engineering auf unsere Infrastruktur ermöglicht eine bessere Risikominderung und erhöhte Beobachtbarkeit, was es uns erlaubt, automatisierte Wiederherstellungsmethoden zu entwickeln, die die Resilienz unserer Plattform im E-Commerce gegenüber allen Betriebsbedingungen verbessern.

Einrichten der Chaos-Experimentumgebung

Installieren Sie LitmusChaos in Ihrem Kubernetes-Cluster:

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

helm repo update

helm install litmus litmuschaos/litmus

Überprüfen Sie die Installation:

kubectl get pods -n litmus

Hinweis: Stellen Sie sicher, dass Ihr Cluster für Chaos-Experimente bereit ist.

Definieren Sie das Chaos-Experiment

Erstellen Sie eine ChaosExperiment YAML-Datei, um ein Szenario für das Löschen von Pods zu simulieren.

Beispiel (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

Installieren Sie ChaosOperator und konfigurieren Sie das Service-Konto

Setzen Sie ChaosOperator ein, um Experimente zu verwalten:

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

Hinweis: Erstellen Sie ein Service-Konto, um die erforderlichen Berechtigungen zu erteilen.

Fügen Sie Chaos in die Zielanwendung ein

Labeln Sie den Anwendungsnamespace für Chaos:

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

Setzen Sie einen ChaosEngine ein, um das Experiment auszulösen:

Beispiel (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

Wenden Sie die ChaosEngine an:

kubectl apply -f chaosengine.yaml

Überwachen Sie das Experiment

Überprüfen Sie den Fortschritt:

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

Überprüfen Sie den Status der Chaos-Pods:

kubectl get pods -n <target-namespace>

Analysieren Sie die Ergebnisse

Nach dem Experiment überprüfen Sie Protokolle und Metriken, um festzustellen, ob die Anwendung sich automatisch erholt hat oder unter Stress versagt hat.

Hier sind einige zu überwachende Metriken:

• Antwortzeit der Anwendung
• Fehlerquoten während und nach dem Experiment
• Zeit, die für die Wiederherstellung der Pods benötigt wird

Lösung

Identifizierter Grund: Während des Hochverkehrs sind Pods aufgrund einer unzureichenden Anzahl von Replikaten im Deployment und unzureichender Ressourcengrenzen ausgefallen.

Angewendete Fixes:

• Erhöht die Anzahl der Replikate im Deployment, um einen höheren Verkehr zu bewältigen
• Konfigurierte angemessene Ressourcenanfragen und -limits für CPU und Speicher in der Pod-Spezifikation
• Implementierte einen Horizontal Pod Autoscaler (HPA), um mit Verkehrsspitzen dynamisch umzugehen

Schlussfolgerung

Die Verwendung von LitmusChaos zur Simulation von Pod-Ausfällen ermöglichte es uns, wesentliche Schwachstellen in der Kubernetes-Bereitstellung der E-Commerce-Plattform zu identifizieren. Das Chaos-Experiment zeigte, dass die Widerstandsfähigkeit durch Skalierungs- und Ressourcenzuweisungsanpassungen erheblich verbessert werden kann. Chaos-Engineering ermöglichte eine proaktive Systemstärkung, was zu einer besseren Betriebszeit und Kundenzufriedenheit führte.