Modern QA2026Хаос-эксперименты Litmus
Join

Course › 05 Performance & Chaos Engineering

Cutting-edge · Chapter 05

Хаос-эксперименты Litmus

Updated Jul 2026

Что такое LitmusChaos?

LitmusChaos — это инкубируемый проект CNCF (Cloud Native Computing Foundation), предоставляющий полноценный фреймворк для практики хаос-инженерии в Kubernetes. Он предлагает богатую библиотеку готовых экспериментов, декларативное определение экспериментов на основе YAML и встроенные пробы для валидации поведения системы во время хаоса.

Для QA-архитекторов, работающих с системами на базе Kubernetes, Litmus является наиболее практичной отправной точкой для хаос-инженерии, поскольку он нативно интегрируется с API Kubernetes и следует привычным паттернам ресурсов Kubernetes.

Архитектура Litmus

  +-------------------+
  | ChaosCenter UI    |  Optional web dashboard for experiment management
  +--------+----------+
           |
           v
  +--------+----------+
  | Chaos Operator    |  Watches for ChaosEngine resources
  | (K8s Controller)  |
  +--------+----------+
           |
           v
  +--------+----------+
  | ChaosEngine       |  Links an experiment to a target application
  +--------+----------+
           |
           v
  +--------+----------+
  | ChaosExperiment   |  Defines WHAT failure to inject (pod-kill, network-loss, etc.)
  +--------+----------+
           |
           v
  +--------+----------+
  | Runner Pod        |  Executes the experiment and collects results
  +--------+----------+
           |
           v
  +--------+----------+
  | ChaosResult       |  Stores the experiment outcome (Pass/Fail/Awaited)
  +------------------+

Написание первого эксперимента: удаление пода

Эксперимент pod-delete проверяет, что ваше приложение переживает завершение пода — самый базовый тест устойчивости. Если ваше приложение не выдерживает уничтожение пода, оно не выдержит ничего.

Шаг 1: Определение ChaosExperiment

# chaos-experiment-pod-delete.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: pod-delete
  namespace: litmus
spec:
  definition:
    scope: Namespaced
    permissions:
      - apiGroups: ["", "apps"]
        resources: ["pods", "deployments"]
        verbs: ["get", "list", "delete"]
    args:
      - -c
      - ./experiments -name pod-delete
    env:
      - name: TOTAL_CHAOS_DURATION
        value: "60"          # chaos lasts 60 seconds
      - name: CHAOS_INTERVAL
        value: "10"          # kill a pod every 10 seconds
      - name: FORCE
        value: "false"       # graceful termination (SIGTERM)
      - name: TARGET_PODS
        value: ""            # random pod selection
      - name: PODS_AFFECTED_PERC
        value: "50"          # kill 50% of pods

Шаг 2: Создание ChaosEngine

ChaosEngine связывает эксперимент с целевым приложением и определяет пробы наблюдаемости:

# chaos-engine-checkout.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: checkout-chaos
  namespace: production
spec:
  appinfo:
    appns: production
    applabel: app=checkout-service
    appkind: deployment
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "120"
            - name: PODS_AFFECTED_PERC
              value: "50"
        probe:
          - name: "checkout-availability"
            type: httpProbe
            mode: Continuous
            httpProbe/inputs:
              url: "https://checkout.internal/health"
              method:
                get:
                  criteria: ==
                  responseCode: "200"
            runProperties:
              probeTimeout: 5s
              interval: 5s
              retry: 2
              probePollingInterval: 2s

Шаг 3: Применение и мониторинг

# Apply the experiment and engine
kubectl apply -f chaos-experiment-pod-delete.yaml
kubectl apply -f chaos-engine-checkout.yaml

# Watch experiment progress
kubectl get chaosengine checkout-chaos -n production -w

# Check results when complete
kubectl get chaosresult checkout-chaos-pod-delete -n production -o yaml

Пробы Litmus: валидация поведения во время хаоса

Пробы — это то, что превращает хаос-эксперименты из «ломаем и надеемся» в «ломаем и измеряем». Litmus поддерживает четыре типа проб:

HTTP-проба

Непрерывно проверяет, что HTTP-эндпоинт возвращает ожидаемые ответы во время хаоса:

probe:
  - name: "api-health-check"
    type: httpProbe
    mode: Continuous
    httpProbe/inputs:
      url: "https://api.internal/health"
      method:
        get:
          criteria: ==
          responseCode: "200"
    runProperties:
      probeTimeout: 10s
      interval: 5s
      retry: 3

Командная проба

Запускает shell-команду и оценивает её код возврата или вывод:

probe:
  - name: "database-connectivity"
    type: cmdProbe
    mode: Edge    # runs at start and end of chaos
    cmdProbe/inputs:
      command: "pg_isready -h db.internal -p 5432"
      comparator:
        type: int
        criteria: ==
        value: "0"   # exit code 0 = success
    runProperties:
      probeTimeout: 15s

Prometheus-проба

Выполняет запросы к Prometheus и проверяет, что значения метрик остаются в допустимых пределах:

probe:
  - name: "error-rate-within-slo"
    type: promProbe
    mode: Continuous
    promProbe/inputs:
      endpoint: "http://prometheus.monitoring:9090"
      query: >
        sum(rate(http_requests_total{status=~"5..",service="checkout"}[5m]))
        /
        sum(rate(http_requests_total{service="checkout"}[5m]))
      comparator:
        type: float
        criteria: <
        value: "0.01"    # error rate must stay under 1%
    runProperties:
      probeTimeout: 10s
      interval: 30s

Kubernetes-проба

Проверяет состояние ресурсов Kubernetes:

probe:
  - name: "min-replicas-available"
    type: k8sProbe
    mode: Continuous
    k8sProbe/inputs:
      group: apps
      version: v1
      resource: deployments
      namespace: production
      fieldSelector: "metadata.name=checkout-service"
      operation: present
    runProperties:
      probeTimeout: 10s
      interval: 10s

Распространённые паттерны экспериментов

Сетевой хаос: моделирование задержки

# network-latency-experiment.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: pod-network-latency
  namespace: litmus
spec:
  definition:
    scope: Namespaced
    env:
      - name: TOTAL_CHAOS_DURATION
        value: "120"
      - name: NETWORK_LATENCY
        value: "500"         # 500ms additional latency
      - name: JITTER
        value: "100"         # +/- 100ms jitter
      - name: DESTINATION_IPS
        value: ""            # all destinations
      - name: DESTINATION_HOSTS
        value: "payment-service.production.svc.cluster.local"

DNS-хаос: моделирование сбоев разрешения имён

# dns-chaos-experiment.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: pod-dns-error
  namespace: litmus
spec:
  definition:
    scope: Namespaced
    env:
      - name: TOTAL_CHAOS_DURATION
        value: "60"
      - name: TARGET_HOSTNAMES
        value: "external-api.vendor.com"
      - name: CHAOS_TYPE
        value: "error"     # return NXDOMAIN for target hostnames

Заполнение диска: моделирование нагрузки на хранилище

# disk-fill-experiment.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosExperiment
metadata:
  name: disk-fill
  namespace: litmus
spec:
  definition:
    scope: Namespaced
    env:
      - name: TOTAL_CHAOS_DURATION
        value: "120"
      - name: FILL_PERCENTAGE
        value: "90"         # fill disk to 90%
      - name: CONTAINER_PATH
        value: "/var/log"   # target the log directory

Автоматизация Litmus в CI/CD

Интегрируйте хаос-эксперименты в ваш пайплайн деплоя, чтобы устойчивость валидировалась при каждом релизе:

# .github/workflows/chaos-gate.yml
name: Chaos Resilience Gate
on:
  push:
    branches: [main]

jobs:
  chaos-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup kubectl
        uses: azure/setup-kubectl@v3

      - name: Deploy to staging
        run: kubectl apply -f k8s/staging/

      - name: Wait for rollout
        run: kubectl rollout status deployment/checkout-service -n staging --timeout=300s

      - name: Run pod-delete chaos experiment
        run: |
          kubectl apply -f chaos/experiments/pod-delete.yaml
          kubectl apply -f chaos/engines/checkout-pod-delete.yaml

      - name: Wait for chaos completion
        run: |
          kubectl wait --for=condition=complete \
            chaosresult/checkout-chaos-pod-delete \
            -n staging --timeout=600s

      - name: Validate chaos result
        run: |
          VERDICT=$(kubectl get chaosresult checkout-chaos-pod-delete \
            -n staging -o jsonpath='{.status.experimentStatus.verdict}')
          echo "Chaos experiment verdict: $VERDICT"
          if [ "$VERDICT" != "Pass" ]; then
            echo "FAIL: System did not survive chaos experiment"
            exit 1
          fi

Лучшие практики проектирования экспериментов

  1. Одна переменная за раз. Не внедряйте сетевую задержку и не уничтожайте поды одновременно в первых экспериментах. Изолируйте переменные, чтобы понять каждый режим отказа независимо.
  2. Определяйте пробы перед запуском. Если вы запускаете эксперимент без проб, вы просто ломаете вещи без измерения воздействия.
  3. Начинайте с наименьшего радиуса поражения. Уничтожьте один под, а не 50%. Добавьте 100 мс задержки, а не 5 секунд. Увеличивайте постепенно по мере роста уверенности.
  4. Документируйте каждый эксперимент. Фиксируйте гипотезу, конфигурацию, результаты и пункты действий. Это создаёт институциональные знания о режимах отказа вашей системы.
  5. Делайте эксперименты идемпотентными. Повторный запуск одного и того же эксперимента не должен оставлять систему в другом состоянии. Litmus автоматически выполняет очистку, но убедитесь, что ваши пробы не создают побочных эффектов.