chaos-operator de Litmus pour injecter des expériences de chaos sur Kubernetes

Codacy Badge

Le chaos operator de Litmus est utilisé par les développeurs d'applications Kubernetes et les SRE pour injecter du chaos dans les applications et l'infrastructure Kubernetes de manière contrôlée. Son objectif est de faciliter le processus de validation et de durcissement des charges de travail applicatives sur Kubernetes en automatisant l'exécution des expériences de chaos. Un exemple de flux d'injection de chaos pourrait être aussi simple que :

• Installer les composants d'infrastructure Litmus (RBAC, CRD), l'Operator et les bundles de ressources personnalisées d'expériences via le manifeste de l'opérateur
• Annoter l'application testée (AUT), en l'activant pour le chaos
• Créer une ressource personnalisée ChaosEngine liée à l'AUT, qui décrit l'expérience à exécuter

Les avantages fournis par le Chaos Operator incluent :

• Spécification standardisée des expériences de chaos
• Bundles de chaos catégorisés pour les applications sans état/avec état/spécifiques au fournisseur
• Résilience des exécutions de test
• Capacité à exécuter le chaos en tant que service d'arrière-plan basé sur des annotations

Qu'est-ce qu'un chaos operator et comment est-il construit ?

Le Chaos Operator est un opérateur Kubernetes, c'est-à-dire des contrôleurs personnalisés avec un accès direct à l'API Kubernetes qui peuvent gérer le cycle de vie de certaines ressources ou applications, tout en s'efforçant toujours de maintenir la ressource dans l'« état souhaité ». La logique qui garantit cela est communément appelée fonction de « réconciliation ».

Le Chaos Operator est construit à l'aide du framework populaire Operator-SDK, qui fournit un support d'amorçage pour les nouveaux projets d'opérateurs, permettant aux équipes de se concentrer sur la logique métier/opérationnelle.

Le Litmus Chaos Operator aide à réconcilier l'état du ChaosEngine, une ressource personnalisée qui contient l'intention de chaos spécifiée par un développeur/ingénieur devops pour un déploiement Kubernetes particulier sans état/avec état. L'opérateur effectue des actions spécifiques lors des opérations CRUD sur le ChaosEngine, sa ressource principale. L'opérateur définit également une ressource secondaire (le pod engine runner), qui est créée et gérée par lui afin de mettre en œuvre les fonctions de réconciliation.

Qu'est-ce qu'un chaos engine ?

Le ChaosEngine est le schéma central qui définit le flux de travail de chaos pour une application donnée. Actuellement, il définit ce qui suit :

• Informations sur l'application (namespace, labels, kind) des applications principales (AUT) et auxiliaires (dépendantes)
• ServiceAccount utilisé pour l'exécution de l'expérience
• Drapeau pour activer/désactiver les vérifications d'annotations de chaos sur les applications
• Expérience de chaos à exécuter sur l'application
• Attributs des expériences (remplace les valeurs par défaut spécifiées dans les CR d'expériences)
• Drapeau pour conserver/nettoyer les ressources de chaos après l'exécution de l'expérience

Le ChaosEngine est référencé comme propriétaire de la ressource secondaire (de réconciliation), avec Kubernetes deletePropagation garantissant que celles-ci sont également supprimées lors de la suppression de la CR ChaosEngine.

Voici un exemple de ChaosEngineSpec pour référence : https://v1-docs.litmuschaos.io/docs/getstarted/#prepare-chaosengine

Qu'est-ce qu'un litmus chaos chart et comment l'utiliser ?

Les Litmus Chaos Charts sont utilisés pour installer des « bundles d'expériences de chaos » et sont catégorisés en fonction de la nature des expériences (chaos Kubernetes général, chaos spécifique au fournisseur/prestataire - comme OpenEBS ou chaos spécifique à une application, par exemple NuoDB). Ils consistent en des ressources personnalisées qui contiennent des paramètres de chaos (test) de bas niveau, interrogés par l'opérateur afin d'exécuter les expériences. Les champs de spec.definition. et leurs valeurs correspondantes sont utilisés pour construire l'artefact d'exécution final qui exécute l'expérience de chaos (généralement le litmusbook, qui est une ressource de type job K8s). Il définit également les permissions nécessaires pour exécuter l'expérience.

Voici un exemple de ChaosEngineSpec pour référence :

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

Comment commencer ?

Consultez la documentation LitmusChaos : documentation Litmus

Comment contribuer ?

Vous pouvez contribuer en signalant des problèmes, en améliorant la documentation, en contribuant au framework et aux outils de base, etc.

Rendez-vous sur le guide de contribution

Licence