Chaos Engineering 101: принципы, процесс и примеры

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

Chaos Engineering позволяет прогнозировать и выявлять потенциальные сбои путем преднамеренного взлома. Таким образом, вы можете найти и исправить сбои до того, как они перерастут в простои. Хаос-инжиниринг — растущая тенденция для DevOps и ИТ-команд. Даже такие компании, как Netflix и Amazon, используют эти принципы при разработке продуктов.

Если вы новичок в технике хаоса, вы попали в нужное место. Сегодня мы подробно расскажем о его принципах и покажем, как начать работу с Kubernetes.

Что такое Chaos Engineering?

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

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

Используя хаос-инжиниринг, мы пытаемся узнать, как вся система реагирует на отказ отдельного компонента.

Например, инженерия хаоса может помочь ответить на такие вопросы о функциональности, как эти:

• Что происходит, когда услуга так или иначе недоступна?
• Каков результат сбоев, когда приложение получает слишком много трафика или когда оно недоступно?
• Будем ли мы сталкиваться с каскадными ошибками, когда из-за единой точки отказа приложение выйдет из строя?
• Что происходит, когда наше приложение выходит из строя?
• Что происходит, когда с сетью что-то не так?

История: Chaos Engineering была впервые разработана Netflix в 2008 году, когда их потоковая служба по подписке была переведена в общедоступное облако. Инженеры Netflix отметили, что им нужны новые способы тестирования этой системы на отказоустойчивость.

Для этого в 2010 году была создана Chaos Monkey. С тех пор хаос инженерии вырос, и такие компании, как Google, Facebook, Amazon и Microsoft, внедрили аналогичные модели тестирования.

Преимущества Chaos Engineering

Хаос-инжиниринг предлагает множество преимуществ, которые недоступны при других формах тестирования программного обеспечения или тестирования сбоев. Тесты на сбой могут проверять только одно условие в двоичной структуре. Это не позволяет нам тестировать систему в условиях беспрецедентных или неожиданных нагрузок.

С другой стороны, Chaos Engineering может объяснить сложные, разнообразные и реальные проблемы или простои. С помощью Chaos Engineering мы можем исправить проблемы и получить новое представление о приложении для будущих улучшений.

Эксперименты с хаосом помогают уменьшить количество отказов и отключений, улучшая наше понимание конструкции нашей системы. Chaos Engineering улучшает доступность и надежность сервиса, поэтому клиенты меньше страдают от простоев. Хаос-инжиниринг также может помочь предотвратить потерю доходов и снизить затраты на обслуживание на уровне бизнеса.

Инструменты Хаоса

Прежде чем мы начнем определять и проводить эксперименты с хаосом, нам нужно выбрать инструмент. Хаос-инжиниринг — это еще не тот сегмент рынка, который хорошо сложился и развился. Тем не менее, есть несколько инструментов, из которых мы можем выбирать.

Один из самых известных инструментов для создания хаоса — это Simian Army, разработанный Netflix. Simian Army лучше всего подходит для облачных сервисов и AWS. Он может генерировать сбои и обнаруживать отклонения от нормы. Chaos Monkey от Netflix — инструмент устойчивости к случайным сбоям.

PowerfulSeal — это мощный инструмент для тестирования кластеров Kubernetes, а Litmus можно использовать для рабочих нагрузок с отслеживанием состояния в Kubernetes. Pumba используется с Docker для тестирования хаоса и эмуляции сети. Gremlin предлагает платформу Chaos Engineering, которая теперь поддерживает тестирование в кластерах Kubernetes.

Chaos Dingo обычно используется для Microsoft Azure, а прокси-сервер Chaos HTTP может использоваться для внесения сбоев в HTTP-запросы.

Принципы и процесс инженерии хаоса

По мере того, как с годами все больше команд проводили эксперименты, они научились наиболее эффективно применять подходы к хаос-инженерии к своим системам. Эти передовые практики стали основными принципами хаос-инжиниринга. Давайте обсудим основные принципы инженерии хаоса, которые каждая команда должна применять в своих экспериментах.

Постройте гипотезу о стационарном состоянии

Вы хотите построить гипотезу о стабильном поведении. Затем вы хотите выполнить потенциально опасные действия с задержкой в ​​сети, приложениями, узлами или любым другим компонентом системы.

Вы хотите создавать ситуации насилия, чтобы подтвердить, что наша стабильная гипотеза верна. вы стремитесь подтвердить, что, когда наша система находится в определенном состоянии, она выполняет определенные действия и завершает такую ​​же проверку, чтобы подтвердить, что состояние не изменилось.

Моделируйте реальные события

Вы хотите создать хаос-инжиниринг на основе реальных событий. Другими словами, копируйте только те события, которые могут произойти в нашей системе. Это включает сбой приложения, нарушение работы сети или отказ узла.

Проведите эксперименты в продакшене

Вы хотите проводить эксперименты с хаосом на производстве. вы хотите поэкспериментировать в производстве, поскольку это «настоящая» система. Если вы проводите эксперименты с хаосом только во время стадии или интеграции, вы не можете получить реальную картину того, как ведет себя производственная система.

Автоматизируйте эксперименты и запускайте их непрерывно

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

Минимизировать радиус взрыва

Вам следует уменьшить радиус взрыва наших экспериментов. Когда вы начинаете с экспериментов с хаосом, вы хотите начать с малого и наращивать свою уверенность в системе. В конце концов, вам следует провести эксперименты во всей системе.

Резюме принципов

• Постройте гипотезу о стационарном состоянии
• Моделируйте реальные события
• Проведите эксперименты в продакшене
• Автоматизируйте эксперименты и запускайте их непрерывно
• Минимизировать радиус взрыва

Хаос инженерный процесс

Общий процесс создания хаоса выглядит следующим образом:

• Определите устойчивую гипотезу: вам нужно начать с представления о том, что может пойти не так. Начните с неудачной инъекции и спрогнозируйте результат, когда она будет запущена в реальном времени.
• Подтвердите установившееся состояние и смоделируйте некоторые реальные события: выполните тесты с использованием реальных сценариев, чтобы увидеть, как ваша система ведет себя в определенных стрессовых условиях или обстоятельствах.
• Еще раз подтвердите установившееся состояние: нам нужно подтвердить, какие изменения произошли, поэтому повторная проверка дает нам представление о поведении системы.
• Собирайте показатели и наблюдайте за информационными панелями: вам необходимо измерить надежность и доступность вашей системы. Лучше всего использовать ключевые показатели производительности, которые коррелируют с успехом клиентов или их использованием. Мы хотим измерить сбой в соответствии с нашей гипотезой, изучив такие факторы, как влияние на задержку или количество запросов в секунду.
• Внесите изменения и исправьте проблемы. После проведения эксперимента вы должны хорошо понимать, что работает, а что нужно изменить. Теперь мы можем определить, что приведет к отключению, и мы точно знаем, что нарушает работу системы. Итак, исправьте это и попробуйте еще раз с новым экспериментом.

Пример Chaos Engineering

Теперь давайте применим всю эту теорию к простому реальному примеру, чтобы лучше понять инженерию хаоса. Мы будем использовать Kubernetes. Для начала создадим кластер Kubernetes. Затем мы развернем наше простое приложение и уничтожим его. Затем мы покажем вам, как определять установившиеся состояния, что имеет решающее значение для инженерии хаоса.

Примечание. Если вы новичок в Kubernetes, мы рекомендуем пройти курс «Практическое руководство по Kubernetes», прежде чем продолжить изучение хаоса. Или вы можете следить за ним, чтобы получить представление о том, как выглядит базовая разработка хаоса.

Создайте кластер Kubernetes

Во-первых, нам нужно уничтожить кластер Kubernetes. Вы можете выбрать Minikube, Docker Desktop, AKS, EKS и GKE. Ниже мы используем Docker Desktop для создания кластера. Если вы хотите узнать, как создать кластер с помощью других инструментов, обратитесь к курсу The DevOps Toolkit: Kubernetes Chaos Engineering.

####################

# Create A Cluster #

####################

# Open Docker Preferences, select the Kubernetes tab, and select the «Enable Kubernetes» checkbox

# Open Docker Preferences, select the Resources > Advanced tab, set CPUs to 4, and Memory to 6.0 GiB, and press the «Apply & Restart» button

#######################

# Destroy the cluster #

#######################

# Open Docker Troubleshoot, and select the «Reset Kubernetes cluster» button

# Select *Quit Docker Desktop*

Клонировать и исследовать репозиторий

Нам нужно развернуть демонстрационное приложение, которое мы подготовили ниже. Мы собираемся клонировать репозиторий, vfarcic/go-demo-8созданный Виктором Фарчичем.

git clone https://github.com/vfarcic/go-demo-8.git

Далее мы заходим в каталог, в котором клонировали репозиторий.

cd go-demo-8
git pull

Теперь создайте пространство имен с именем go-demo-8.

kubectl create namespace go-demo-8

Теперь давайте кратко рассмотрим приложение, которое мы собираемся развернуть, расположенное в terminate-podsкаталоге в файле с именем pod.yaml.

---
 
apiVersion: v1
kind: Pod
metadata:
  name: go-demo-8
  labels:
    app: go-demo-8
spec:
  containers:
  - name: go-demo-8
    image: vfarcic/go-demo-8:0.0.1
    env:
    - name: DB
      value: go-demo-8-db
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /
        port: 8080
    readinessProbe:
      httpGet:
        path: /
        port: 8080
    resources:
        limits:
          cpu: 100m
          memory: 50Mi
        requests:
          cpu: 50m
          memory: 20Mi

Это приложение определяется как один модуль с одним контейнером go-demo-8. Он включает в себя другие ресурсы, такие как livenessProbeи readinessProbe.

Применение определения к кластеру

Теперь мы применяем это определение к нашему кластеру внутри go-demo-8пространства имен. Это заставит наше приложение работать как Pod.

kubectl --namespace go-demo-8 apply --filename k8s/terminate-pods/pod.yaml

Пришло время нанести урон и уничтожить наше приложение!

Установите плагин Chaos Toolkit Kubernetes

Чтобы проводить эксперименты с хаосом в нашем приложении, мы можем использовать плагин Chaos Toolkit для Kubernetes. Этот инструментарий не поддерживает Kubernetes из коробки. Нам нужен плагин для функций, выходящих за рамки базовых готовых функций. Давайте установим плагин Kubernetes, используя pip.

pip install -U chaostoolkit-kubernetes

Примечание. Изучите плагин Chaos Toolkit с помощью discoverкоманды, чтобы увидеть все его функции, параметры и аргументы.

Завершение работы экземпляров приложения

Начнем разрушать. Посмотрите на первое определение, которое мы будем использовать, расположенное в chaosкаталоге файла terminate-pod.yaml.

cat chaos/terminate-pod.yaml

Это дает нам следующий результат:

version: 1.0.0
title: What happens if we terminate a Pod?
description: If a Pod is terminated, a new one should be created in its places.
tags:
- k8s
- pod
method:
- type: action
  name: terminate-pod
  provider:
    type: python
    module: chaosk8s.pod.actions
    func: terminate_pods
    arguments:
      label_selector: app=go-demo-8
      rand: true
      ns: go-demo-8

Теперь, когда мы ознакомились с определением, приступим terminate-pod.yaml.

chaos run chaos/terminate-pod.yaml

Результат выглядит следующим образом:

[... INFO] Validating the experiment's syntax
[... INFO] Experiment looks valid
[... INFO] Running experiment: What happens if we terminate a Pod?
[... INFO] No steady state hypothesis defined. That's ok, just exploring.
[... INFO] Action: terminate-pod
[... INFO] No steady state hypothesis defined. That's ok, just exploring.
[... INFO] Let's rollback...
[... INFO] No declared rollbacks, let's move on.
[... INFO] Experiment ended with status: completed

После первоначальной проверки он провел эксперимент под названием What happens if we terminate a Pod?и обнаружил, что есть no steady state hypothesis defined. Судя по выводу, действие одно terminate-pod.

Затем он вернулся к steady state hypothesisи определил, что его нет. Затем он попытался rollbackи обнаружил, что не может. Все, что мы сделали до сих пор, — это выполнить действие по завершению работы Pod. Мы можем увидеть результат в последней строке: experiment ended with status: complete.

Теперь давайте выведем код выхода предыдущей команды. Если мы получим 0, это означает успех в Linux. Эти коды выхода сообщают системе, неудача это или успех!

Теперь давайте посмотрим на модули в нашем пространстве имен.

kubectl --namespace go-demo-8 get pods

В выводе указано, что no resourcesбыли found in go-demo-8 namespace. Мы развернули единственный контейнер и провели эксперимент, в результате которого он был уничтожен. Мы не проводили никаких проверок. А также мы выполнили одно действие для завершения работы Pod, которое было успешным.

Определение устойчивых состояний

Выше все, что мы сделали, это уничтожили капсулу. Однако цель инженерии хаоса — найти слабые места в наших кластерах. Итак, мы обычно начинаем определять устойчивое состояние, которое тестируем до и после эксперимента.

Если состояние до и после одинаково, мы можем сделать вывод, что наш кластер отказоустойчив в этом случае. В случае Chaos Toolkit мы достигаем этого путем определения steady state hypothesis.

Мы собираемся рассмотреть определение, которое указывает состояние, которое будет проверяться до и после действия.

cat chaos/terminate-pod-ssh.yaml

Результат даст нам:

> steady-state-hypothesis:
>   title: Pod exists
>   probes:
>   - name: pod-exists
>     type: probe
>     tolerance: 1
>     provider:
>       type: python
>       func: count_pods
>       module: chaosk8s.pod.probes
>       arguments:
>         label_selector: app=go-demo-8
>         ns: go-demo-8

Новый раздел есть steady-state-hypothesis. Теперь мы можем провести настоящий эксперимент с хаосом, чтобы проверить наше устойчивое состояние.

Запуск эксперимента с хаосом и проверка вывода

Давайте проведем эксперимент с хаосом, чтобы увидеть правильный результат.

chaos run chaos/terminate-pod-ssh.yaml

Получаем следующее:

[... INFO] Validating the experiment's syntax
[... INFO] Experiment looks valid
[... INFO] Running experiment: What happens if we terminate a Pod?
[... INFO] Steady state hypothesis: Pod exists
[... INFO] Probe: pod-exists
[... CRITICAL] Steady state probe 'pod-exists' is not in the given tolerance so failing this experiment
[... INFO] Let's rollback...
[... INFO] No declared rollbacks, let's move on.
[... INFO] Experiment ended with status: failed

Существует важный вопрос здесь: Steady state probe ’pod-exists’ is not in the given tolerance. Зонд не удался, прежде чем мы выполнили действия, потому что мы уничтожили контейнер. Итак, наш эксперимент провалился и подтвердил, что начальное состояние не соответствует тому, что мы хотим.

Итак, давайте применим terminate-pods/pod.yamlопределение, чтобы воссоздать Pod. Затем мы можем увидеть, что произойдет, когда мы повторно запустим эксперимент с steady-state-hypothesis.

kubectl --namespace go-demo-8 apply --filename k8s/terminate-pods/pod.yaml

Повторить эксперимент

С нашей капсулой обратно, и можно повторно запустить эксперимент.

chaos run chaos/terminate-pod-ssh.yaml

Результат выглядит следующим образом:

[... INFO] Validating the experiment's syntax
[... INFO] Experiment looks valid
[... INFO] Running experiment: What happens if we terminate a Pod?
[... INFO] Steady state hypothesis: Pod exists
[... INFO] Probe: pod-exists
[... INFO] Steady state hypothesis is met!
[... INFO] Action: terminate-pod
[... INFO] Steady state hypothesis: Pod exists
[... INFO] Probe: pod-exists
[... INFO] Steady state hypothesis is met!
[... INFO] Let's rollback...
[... INFO] No declared rollbacks, let's move on.
[... INFO] Experiment ended with status: completed

Теперь мы видим, что зонд pod-existsподтвердил правильное состояние и действие terminate-podбыло выполнено. Мы также можем видеть, что установившееся состояние было переоценено. Стручок существовал до действия, а Под существовал после действия. Но как может Стручок существовать, если мы его уничтожим?

Добавление паузы

Эксперимент не провалился, потому что наши исследования и действия выполнялись сразу одно за другим. Kubernetes не успел полностью удалить модуль. Итак, нам нужно добавить паузу, чтобы эксперимент был более полезным. Давайте посмотрим на YAML.

cat chaos/terminate-pod-pause.yaml

Это дает нам следующий результат:

>   pauses: 
>     after: 10

Мы видим здесь, что мы добавили pausesраздел после того action, как завершает Pod. Теперь, когда мы выполняем действие по завершению работы Pod, система будет ждать 10 секунд перед проверкой нашего состояния.

Проведите эксперимент с паузой

Посмотрим, что мы получим, если проведем этот эксперимент с паузой.

chaos run chaos/terminate-pod-pause.yaml

Это дает нам следующий результат:

[... INFO] Validating the experiment's syntax
[... INFO] Experiment looks valid
[... INFO] Running experiment: What happens if we terminate a Pod?
[... INFO] Steady state hypothesis: Pod exists
[... INFO] Probe: pod-exists
[... INFO] Steady state hypothesis is met!
[... INFO] Action: terminate-pod
[... INFO] Pausing after activity for 10s...
[... INFO] Steady state hypothesis: Pod exists
[... INFO] Probe: pod-exists
[... CRITICAL] Steady state probe 'pod-exists' is not in the given tolerance so failing this experiment
[... INFO] Let's rollback...
[... INFO] No declared rollbacks, let's move on.
[... INFO] Experiment ended with status: deviated
[... INFO] The steady-state has deviated, a weakness may have been discovered

На этот раз зонд отказал и сказал это steady state probe ’pod-exists’ is not in the given tolerance so failing this experiment. Теперь мы дали Kubernetes достаточно времени, чтобы удалить Pod, а затем проверили, существует ли Pod.

Система вернулась к нам и сообщила, что модуля нет. Мы можем вывести код выхода последней команды, чтобы убедиться, что она действительно не сработала.