Litmus chaos-operator para injeção de experimentos de caos no Kubernetes

Codacy Badge

O operador de caos Litmus é usado por desenvolvedores de aplicações Kubernetes e SREs para injetar caos nas aplicações e na infraestrutura Kubernetes de forma gerenciada. Seu objetivo é facilitar o processo de validação e endurecimento (hardening) de cargas de trabalho de aplicações no Kubernetes, automatizando a execução de experimentos de caos. Um exemplo de fluxo de trabalho de injeção de caos pode ser tão simples quanto:

• Instale os componentes de infraestrutura do Litmus (RBAC, CRDs), o Operador e os pacotes de recursos personalizados de Experimentos por meio do manifesto do operador
• Anote o aplicativo em teste (AUT), habilitando-o para caos
• Crie um recurso personalizado ChaosEngine vinculado ao AUT, que descreve o experimento a ser executado

Os benefícios fornecidos pelo Chaos Operator incluem:

• Especificação padronizada de experimentos de caos
• Pacotes de caos categorizados para stateless/stateful/específicos de fornecedor
• Resiliência de execução de teste
• Capacidade de executar o caos como um serviço em segundo plano com base em anotações

O que é um operador de caos e como ele é construído?

O Chaos Operator é um Operador Kubernetes, que nada mais são do que controladores personalizados com acesso direto à API do Kubernetes que podem gerenciar o ciclo de vida de determinados recursos ou aplicações, sempre tentando garantir que o recurso esteja no "estado desejado". A lógica que garante isso é comumente chamada de função "reconcile".

O Chaos Operator é construído usando o popular framework Operator-SDK, que fornece suporte de inicialização (bootstrap) para novos projetos de operadores, permitindo que as equipes se concentrem na lógica de negócios/operacional.

O Litmus Chaos Operator ajuda a reconciliar o estado do ChaosEngine, um recurso personalizado que contém a intenção de caos especificada por um desenvolvedor/engenheiro de devops em relação a uma implantação Kubernetes específica stateless/stateful. O operador executa ações específicas nas operações de CRUD do ChaosEngine, seu recurso primário. O operador também define um recurso secundário (o pod runner do engine), que é criado e gerenciado por ele para implementar as funções de reconciliação.

O que é um chaos engine?

O ChaosEngine é o esquema central que define o fluxo de trabalho de caos para uma determinada aplicação. Atualmente, ele define o seguinte:

• Informações da aplicação (namespace, labels, kind) das aplicações primária (AUT) e auxiliares (dependentes)
• ServiceAccount usada para a execução do experimento
• Flag para ativar/desativar verificações de anotação de caos nas aplicações
• Experimento de Caos a ser executado na aplicação
• Atributos dos experimentos (substitui os padrões especificados nos CRs de experimento)
• Flag para reter/limpar os recursos de caos após a execução do experimento

O ChaosEngine é referenciado como o proprietário do recurso secundário (de reconciliação), com o deletePropagation do Kubernetes garantindo que esses recursos também sejam removidos quando o CR do ChaosEngine for excluído.

Aqui está um exemplo de ChaosEngineSpec para referência: https://v1-docs.litmuschaos.io/docs/getstarted/#prepare-chaosengine

O que é um litmus chaos chart e como posso usá-lo?

Os Litmus Chaos Charts são usados para instalar "Pacotes de Experimentos de Caos" e são categorizados com base na natureza dos experimentos (caos geral do Kubernetes, caos específico de fornecedor/provedor — como OpenEBS — ou caos específico de aplicação, por exemplo NuoDB). Eles consistem em recursos personalizados que contêm parâmetros de baixo nível de caos (teste) que são consultados pelo operador para executar os experimentos. Os campos de spec.definition e seus valores correspondentes são usados para construir o artefato de execução final que executa o experimento de caos (normalmente, o litmusbook, que é um recurso de job K8s). Ele também define as permissões necessárias para executar o experimento.

Aqui está um exemplo de ChaosEngineSpec para referência:

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

Como começar?

Consulte a documentação do LitmusChaos litmus docs

Como posso contribuir?

Você pode contribuir abrindo issues, melhorando a documentação, contribuindo com o framework central e as ferramentas, etc.

Acesse o Guia de contribuição

Licença