Litmus chaos-operator для внедрения хаос-экспериментов в Kubernetes

Litmus chaos operator используется разработчиками приложений Kubernetes и SRE-инженерами для внедрения хаоса в приложения и инфраструктуру Kubernetes управляемым образом. Его цель — упростить процесс проверки и укрепления рабочих нагрузок приложений на Kubernetes за счёт автоматизации выполнения хаос-экспериментов. Пример рабочего процесса внедрения хаоса может быть таким:

Установите компоненты инфраструктуры Litmus (RBAC, CRDs), Operator и пакеты пользовательских ресурсов Experiment с помощью манифеста оператора
Аннотируйте тестируемое приложение (AUT), включив его для хаоса
Создайте пользовательский ресурс ChaosEngine, привязанный к AUT, который описывает эксперимент, который нужно выполнить

Преимущества, предоставляемые Chaos Operator, включают:

Стандартизированная спецификация хаос-экспериментов
Категоризированные пакеты хаоса для stateless/stateful/вендор-специфичных сред
Отказоустойчивость тестовых запусков
Возможность запускать хаос в качестве фонового сервиса на основе аннотаций

Что такое chaos operator и как он устроен?

Chaos Operator — это Kubernetes Operator, которые представляют собой не что иное, как пользовательские контроллеры с прямым доступом к API Kubernetes, способные управлять жизненным циклом определённых ресурсов или приложений, всегда стремясь обеспечить нахождение ресурса в «желаемом состоянии». Логика, которая это обеспечивает, обычно называется функцией «reconcile».

Chaos Operator построен с использованием популярного фреймворка Operator-SDK, который обеспечивает начальную поддержку новых операторных проектов, позволяя командам сосредоточиться на бизнес- и операционной логике.

Litmus Chaos Operator помогает согласовывать состояние ChaosEngine — пользовательского ресурса, который содержит намерение по хаосу, заданное разработчиком/devops-инженером для конкретного stateless/stateful развёртывания Kubernetes. Оператор выполняет определённые действия при CRUD-операциях с ChaosEngine, своим основным ресурсом. Оператор также определяет вторичный ресурс (pod запуска движка), который создаётся и управляется им для реализации функций reconcile.

Что такое chaos engine?

ChaosEngine — это базовая схема, которая определяет рабочий процесс хаоса для конкретного приложения. В настоящее время она определяет следующее:

Информация о приложении (namespace, labels, kind) для основного (AUT) и вспомогательного (зависимого) приложений
ServiceAccount, используемый для выполнения эксперимента
Флаг для включения/выключения проверок аннотаций хаоса на приложениях
Хаос-эксперимент, который должен быть выполнен на приложении
Атрибуты экспериментов (переопределяют значения по умолчанию, указанные в CR экспериментов)
Флаг для сохранения/очистки ресурсов хаоса после выполнения эксперимента

ChaosEngine указывается как владелец вторичного (reconcile) ресурса, при этом deletePropagation в Kubernetes гарантирует, что эти ресурсы также будут удалены при удалении CR ChaosEngine.

Вот пример ChaosEngineSpec для справки: https://v1-docs.litmuschaos.io/docs/getstarted/#prepare-chaosengine

Что такое litmus chaos chart и как я могу его использовать?

Litmus Chaos Charts используются для установки «пакетов хаос-экспериментов» и категоризируются по характеру экспериментов (общий Kubernetes-хаос, вендор-/провайдер-специфичный хаос — например, OpenEBS или специфичный для приложений хаос, скажем, NuoDB). Они состоят из пользовательских ресурсов, содержащих низкоуровневые параметры хаоса (теста), которые запрашиваются оператором для выполнения экспериментов. Поля из spec.definition и соответствующие им значения используются для создания конечного артефакта выполнения, который запускает хаос-эксперимент (обычно это litmusbook, представляющий собой ресурс K8s job). Он также определяет разрешения, необходимые для выполнения эксперимента.

Вот пример ChaosEngineSpec для справки:

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

Как начать работу?

Обратитесь к документации LitmusChaos: litmus docs

Как я могу внести вклад?

Вы можете внести вклад, создавая issues, улучшая документацию, внося изменения в базовый фреймворк и инструментарий и т.д.

Перейдите к руководству по внесению вклада

chaos-operator

Популярное