Litmus chaos-operator zum Injizieren von Chaos-Experimenten in Kubernetes

Codacy Badge

Der Litmus Chaos Operator wird von Kubernetes-Anwendungsentwicklern und SREs verwendet, um kontrolliert Chaos in Anwendungen und in die Kubernetes-Infrastruktur zu injizieren. Sein Ziel ist es, die Validierung und Härtung von Anwendungsworkloads auf Kubernetes durch die Automatisierung der Ausführung von Chaos-Experimenten zu vereinfachen. Ein beispielhafter Chaos-Injektions-Workflow kann so einfach sein wie:

• Installieren der Litmus-Infrastrukturkomponenten (RBAC, CRDs), des Operators & der Experiment-Custom-Resource-Bündel über das Operator-Manifest
• Annotieren der zu testenden Anwendung (AUT), um sie für Chaos zu aktivieren
• Erstellen einer an die AUT gebundenen ChaosEngine-Custom-Resource, die das auszuführende Experiment beschreibt

Zu den Vorteilen des Chaos Operators gehören:

• Standardisierte Chaos-Experiment-Spezifikation
• Kategorisierte Chaos-Bündel für zustandslose/zustandsbehaftete/anbieterspezifische Umgebungen
• Resilienz bei Testläufen
• Möglichkeit, Chaos basierend auf Annotationen als Hintergrunddienst auszuführen

Was ist ein Chaos Operator und wie ist er aufgebaut?

Der Chaos Operator ist ein Kubernetes-Operator. Kubernetes-Operatoren sind nichts anderes als benutzerdefinierte Controller mit direktem Zugriff auf die Kubernetes-API, die den Lebenszyklus bestimmter Ressourcen oder Anwendungen verwalten können und dabei stets versuchen, die Ressource im "gewünschten Zustand" zu halten. Die Logik, die dies sicherstellt, wird üblicherweise als "Reconcile"-Funktion bezeichnet.

Der Chaos Operator wird mit dem beliebten Operator-SDK-Framework erstellt, das Bootstrap-Unterstützung für neue Operator-Projekte bietet und es Teams ermöglicht, sich auf die geschäftliche/betriebliche Logik zu konzentrieren.

Der Litmus Chaos Operator hilft beim Abgleichen (Reconcile) des Zustands der ChaosEngine, einer benutzerdefinierten Ressource, die die Chaos-Absicht enthält, die ein Entwickler/DevOps-Ingenieur für ein bestimmtes zustandsloses/zustandsbehaftetes Kubernetes-Deployment festgelegt hat. Der Operator führt bei CRUD-Operationen der ChaosEngine, seiner primären Ressource, spezifische Aktionen aus. Der Operator definiert außerdem eine sekundäre Ressource (den Engine-Runner-Pod), die von ihm erstellt und verwaltet wird, um die Reconcile-Funktionen zu implementieren.

Was ist eine Chaos Engine?

Die ChaosEngine ist das zentrale Schema, das den Chaos-Workflow für eine bestimmte Anwendung definiert. Derzeit definiert sie Folgendes:

• Anwendungsinformationen (Namespace, Labels, Art) der primären (AUT) und Hilfs- (abhängigen) Anwendungen
• ServiceAccount, der für die Ausführung des Experiments verwendet wird
• Flag zum Aktivieren/Deaktivieren von Chaos-Annotationsprüfungen an Anwendungen
• Chaos-Experiment, das an der Anwendung ausgeführt werden soll
• Attribute der Experimente (überschreibt in den Experiment-CRs festgelegte Standardwerte)
• Flag zum Behalten/Bereinigen von Chaos-Ressourcen nach der Ausführung des Experiments

Die ChaosEngine wird als Eigentümer der sekundären (Reconcile-)Ressource referenziert, wobei die Kubernetes deletePropagation sicherstellt, dass diese ebenfalls entfernt werden, wenn die ChaosEngine-CR gelöscht wird.

Hier ist eine Beispiel-ChaosEngineSpec als Referenz: https://v1-docs.litmuschaos.io/docs/getstarted/#prepare-chaosengine

Was ist ein Litmus Chaos Chart und wie kann ich es verwenden?

Litmus Chaos Charts werden verwendet, um "Chaos-Experiment-Bündel" zu installieren, und sind basierend auf der Art der Experimente kategorisiert (allgemeines Kubernetes-Chaos, anbieter-/hersteller-spezifisches Chaos – z. B. OpenEBS oder anwendungsspezifisches Chaos, etwa NuoDB). Sie bestehen aus benutzerdefinierten Ressourcen, die Low-Level-Chaos(Test)- Parameter enthalten, die vom Operator abgefragt werden, um die Experimente auszuführen. Die Felder der spec.definition und ihre entsprechenden Werte werden verwendet, um das letztendliche Ausführungsartefakt zu erstellen, das das Chaos- Experiment ausführt (typischerweise das LitmusBook, eine K8s-Job-Ressource). Sie definieren außerdem die Berechtigungen, die zur Ausführung des Experiments erforderlich sind.

Hier ist eine Beispiel-ChaosEngineSpec als Referenz:

apiVersion: litmuschaos.io/v1alpha1
description:
  message: |
    Deletes a pod belonging to a deployment/statefulset/daemonset
kind: ChaosExperiment
metadata:
  name: pod-delete
  labels:
    name: pod-delete
    app.kubernetes.io/part-of: litmus
    app.kubernetes.io/component: chaosexperiment
    app.kubernetes.io/version: latest
spec:
  definition:
    scope: Namespaced
    permissions:
      - apiGroups:
          - ""
          - "apps"
          - "batch"
          - "litmuschaos.io"
        resources:
          - "deployments"
          - "jobs"
          - "pods"
          - "configmaps"
          - "chaosengines"
          - "chaosexperiments"
          - "chaosresults"
        verbs:
          - "create"
          - "list"
          - "get"
          - "patch"
          - "update"
          - "delete"
    image: "litmuschaos/go-runner:latest"
    imagePullPolicy: Always
    args:
    - -c
    - ./experiments -name pod-delete
    command:
    - /bin/bash
    env:

    - name: TOTAL_CHAOS_DURATION
      value: '15'

    # Period to wait before/after injection of chaos in sec
    - name: RAMP_TIME
      value: ''

    - name: FORCE
      value: 'true'

    - name: CHAOS_INTERVAL
      value: '5'

    ## percentage of total pods to target
    - name: PODS_AFFECTED_PERC
      value: ''

    - name: LIB
      value: 'litmus'    

    - name: TARGET_PODS
      value: ''

    ## it defines the sequence of chaos execution for multiple target pods
    ## supported values: serial, parallel
    - name: SEQUENCE
      value: 'parallel'
    labels:
      name: pod-delete
      app.kubernetes.io/part-of: litmus
      app.kubernetes.io/component: experiment-job
      app.kubernetes.io/version: latest

Wie starte ich?

Siehe die LitmusChaos-Dokumentation Litmus Docs

Wie kann ich beitragen?

Du kannst beitragen, indem du Issues erstellst, die Dokumentation verbesserst, zum Kernframework und zu den Werkzeugen beiträgst usw.

Schau in den Beitragsleitfaden

Lizenz