Kube-monkey

Хаос-инжиниринг для Kubernetes становится всё популярнее, и это закономерно: ведь такая инфраструктура создавалась быть готовой к тому, чтобы в любой момент что-нибудь отстрелило. А значит это замечательное свойство надо проверять в реальных проектах.

Благо, уже сегодня можно найти не одно Open Source-решение, помогающее в подобных экспериментах. Представляем вашему вниманию их обзор. Он получился весьма объёмным, поэтому был разбит на две части: в этой мы рассмотрим три популярных проекта.

Предыстория

История chaos engineering начинается в 2011, когда в компании Netflix решили, что только избыточная и распределенная инфраструктура может дать действительно высокую отказоустойчивость. Для того, чтоб непрерывно убеждаться в том, что это действительно так, они и создали Chaos Monkey.

Суть этой обезьяны сводилась к тому, чтобы регулярно убивать один из экземпляров какого-то сервиса, будь то виртуальная машина или контейнер. Увеличение размера инфраструктуры и эволюция привели к появлению Chaos Kong сервиса, который отрубает один из трёх регионов AWS. Вот это по-настоящему масштабная проверка отказоустойчивости!

В целом же, список доступных действий для хаос-инжиниринга значительно шире, чем простое убийство сервисов. Главная цель этой новой науки обнаружение вероятных проблем, которые либо не устраняются должным образом, либо не обнаруживаются / не воспроизводятся постоянно. Поэтому убийством не ограничиваются: нужно ещё умело вставлять палки в колёса и дисковую подсистему, рвать сетевые соединения и поджаривать CPU с памятью особо продвинутые могут даже фрагментировать страницы памяти в ядре запущенного pod'а (как это вообще, cgroups?).

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

Возвращаясь же к классическому Chaos Monkey: эта утилита была создана и используется в Netflix. В настоящий момент она интегрирована с платформой непрерывной доставки Spinnaker, поэтому работает с любым поддерживаемым там бэкендом: AWS, Google Compute Engine, Azure, Kubernetes, Cloud Foundry.

Однако такое, казалось бы, удобство таит в себе обратную сторону. Установка/настройка Chaos Monkey для Kubernetes (в связке со Spinnaker) по своей простоте очень далека от привычного Helm-чарта Далее будут рассмотрены инструменты для chaos engineering, созданные специально для K8s.

1. kube-monkey

GitHub: https://github.com/asobti/kube-monkey
Звёзды / контрибьюторы: ~1800 / 20+
Язык: Go

Один из самых старых проектов среди изначально ориентированных на Kubernetes: первые публичные коммиты в его репозитории состоялись в декабре 2016 года. Попробуем его сразу в деле на развёрнутом deployment'е nginx из пяти реплик, попутно рассказывая о возможностях.

Итак, вот манифест для испытаний:

---apiVersion: v1kind: Namespacemetadata:  name: test-monkeysspec:  finalizers:  - kubernetes---apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx  namespace: test-monkeysspec:  selector:    matchLabels:      app: nginx  replicas: 5  template:    metadata:      labels:        app: nginx    spec:      containers:      - name: nginx        image: nginx:1.16        ports:        - containerPort: 80---

Готовый чарт с kube-monkey самый простой вариант установки и запуска утилиты:

$ git clone https://github.com/asobti/kube-monkey$ cd kube-monkey/helm

Немного модифицируем команду из README.md, чтобы обезьянка жила в своём namespace и начинала работу в двенадцать ночи по Москве, заканчивая за час до полуночи (такое расписание подходило нам на момент написания статьи):

$ helm install -n kubemonkey --namespace kubemonkey --set config.dryRun=false --set config.runHour=0 --set config.startHour=1 --set config.endHour=23 --set config.timeZone=Europe/Moscow --set config.debug.schedule_immediate_kill=true --set config.debug.enabled=true kubemonkey

Теперь можно натравить обезьянку на nginx с помощью лейблов. Kube-monkey работает по принципу opt-in, т.е. взаимодействует только с теми ресурсами, которые разрешено убивать:

$ kubectl -n test-monkeys label deployment nginx kube-monkey/enabled=enabled$ kubectl -n test-monkeys label deployment nginx kube-monkey/kill-mode=random-max-percent$ kubectl -n test-monkeys label deployment nginx kube-monkey/kill-value=100$ kubectl -n test-monkeys label deployment nginx kube-monkey/identifier=nginx

Пояснения по лейблам:

Второй и третий (kill-mode, kill-value) говорят kube-monkey убивать случайное количество pod'ов из StatefulSets/Deployments/DaemonSets, вплоть до 100%.
Четвёртый (identifier) определяет уникальный лейбл, по которому kube-monkey найдёт жертв.
Пятый (mtbf mean time between failure) определяет, сколько дней должно пройти между убийствами (по умолчанию равен единице).

Сразу появляется ощущение, что пять лейблов это многовато, чтобы просто взять и кого-то поубивать Кроме того, есть pull request о том, чтобы mtbf указывать не только в днях (но и в часах, например, чтобы чаще совершать злодеяния). Однако он висит с 5 февраля без движения, что печально.

Ок, посмотрим на логи обезьянки и увидим в конце:

I0831 18:14:53.772484       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 secI0831 18:15:23.773017       1 schedule.go:64] Status Update: Generating schedule for terminationsI0831 18:15:23.811425       1 schedule.go:57] Status Update: 1 terminations scheduled todayI0831 18:15:23.811462       1 schedule.go:59] v1.Deployment nginx scheduled for termination at 08/31/2020 21:16:11 +0300 MSKI0831 18:15:23.811491       1 kubemonkey.go:62] Status Update: Waiting to run scheduled terminations.********** Today's schedule **********k8 Api Kind    Kind Name        Termination Time-----------    ---------        ----------------v1.Deployment    nginx        08/31/2020 21:16:11 +0300 MSK********** End of schedule **********

Ура! Chaos-monkey нашла deployment и запланировала убийство одной или более из его реплик. Но что же это и почему?

E0831 18:16:11.869463       1 kubemonkey.go:68] Failed to execute termination for v1.Deployment nginx. Error: v1.Deployment nginx has no running pods at the moment

Посмотрим внимательно в мануал ещё раз и увидим (с устаревшим apiVersion, к сожалению):

For newer versions of kubernetes you may need to add the labels to the k8s app metadata as well.

---apiVersion: extensions/v1beta1kind: Deploymentmetadata:  name: monkey-victim  namespace: app-namespace  labels:    kube-monkey/enabled: enabled    kube-monkey/identifier: monkey-victim    kube-monkey/mtbf: '2'    kube-monkey/kill-mode: "fixed"    kube-monkey/kill-value: '1'spec:  template:    metadata:      labels:        kube-monkey/enabled: enabled        kube-monkey/identifier: monkey-victim[... omitted ...]

Ок, изменяем наш шаблон с удалением deployment'а на:

---apiVersion: apps/v1kind: Deploymentmetadata:  name: nginx  namespace: test-monkeys  labels:    kube-monkey/enabled: enabled    kube-monkey/identifier: nginx    kube-monkey/kill-mode: random-max-percent    kube-monkey/kill-value: "100"    kube-monkey/mtbf: "1"spec:  selector:    matchLabels:      app: nginx  replicas: 5  template:    metadata:      labels:        app: nginx        kube-monkey/enabled: enabled        kube-monkey/identifier: nginx    spec:      containers:      - name: nginx        image: nginx:1.16        ports:        - containerPort: 80---

Теперь все получилось:

I0831 18:24:20.434516       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 secI0831 18:24:50.434838       1 schedule.go:64] Status Update: Generating schedule for terminations    ********** Today's schedule **********    k8 Api Kind    Kind Name        Termination Time    -----------    ---------        ----------------    v1.Deployment    nginx        08/31/2020 21:25:03 +0300 MSK    ********** End of schedule **********I0831 18:24:50.481865       1 schedule.go:57] Status Update: 1 terminations scheduled todayI0831 18:24:50.481917       1 schedule.go:59] v1.Deployment nginx scheduled for termination at 08/31/2020 21:25:03 +0300 MSKI0831 18:24:50.481971       1 kubemonkey.go:62] Status Update: Waiting to run scheduled terminations.I0831 18:25:03.540282       1 kubemonkey.go:70] Termination successfully executed for v1.Deployment nginxI0831 18:25:03.540324       1 kubemonkey.go:73] Status Update: 0 scheduled terminations left.I0831 18:25:03.540338       1 kubemonkey.go:76] Status Update: All terminations done.I0831 18:25:03.540499       1 kubemonkey.go:19] Debug mode detected!I0831 18:25:03.540522       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 sec

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

I0831 18:30:33.163500       1 kubemonkey.go:19] Debug mode detected!I0831 18:30:33.163513       1 kubemonkey.go:20] Status Update: Generating next schedule in 30 secI0831 18:31:03.163706       1 schedule.go:64] Status Update: Generating schedule for terminationsI0831 18:31:03.204975       1 schedule.go:57] Status Update: 1 terminations scheduled today    ********** Today's schedule **********    k8 Api Kind    Kind Name        Termination Time    -----------    ---------        ----------------    v1.Deployment    nginx        08/31/2020 21:31:45 +0300 MSK    ********** End of schedule **********I0831 18:31:03.205027       1 schedule.go:59] v1.Deployment nginx scheduled for termination at 08/31/2020 21:31:45 +0300 MSKI0831 18:31:03.205080       1 kubemonkey.go:62] Status Update: Waiting to run scheduled terminations.E0831 18:31:45.250587       1 kubemonkey.go:68] Failed to execute termination for v1.Deployment nginx. Error: no terminations requested for v1.Deployment nginxI0831 18:31:45.250634       1 kubemonkey.go:73] Status Update: 0 scheduled terminations left.I0831 18:31:45.250649       1 kubemonkey.go:76] Status Update: All terminations done.I0831 18:31:45.250828       1 kubemonkey.go:19] Debug mode detected!

2. chaoskube

GitHub: https://github.com/linki/chaoskube
Звёзды / контрибьюторы: ~1200 / 20+
Язык: Go

Эта утилита тоже может похвастать длинной историей: первый её релиз состоялся в ноябре 2016 года. У chaoskube есть готовый чарт и хороший мануал по нему. По умолчанию запускается в режиме dry-run, поэтому никто не пострадает.

Запустим на простом deployment'е с nginx, живущем в пространстве имен test-monkey, и укажем опцию про создание RBAC (потому что у роли default нет нужных прав):

$ helm install --name chaoskube --set dryRun=false --set namespaces="test-monkeys" --set rbac.create=true --set rbac.serviceAccountName=chaoskube stable/chaoskube

дело сразу пошло!

$ kubectl -n default logs chaoskube-85f8bf9979-j75qmtime="2020-09-01T08:33:11Z" level=info msg="starting up" dryRun=false interval=10m0s version=v0.14.0time="2020-09-01T08:33:11Z" level=info msg="connected to cluster" master="http://personeltest.ru/aways/10.222.0.1:443" serverVersion=v1.16.10time="2020-09-01T08:33:11Z" level=info msg="setting pod filter" annotations= excludedPodNames="<nil>" includedPodNames="<nil>" labels= minimumAge=0s namespaces=test-monkeystime="2020-09-01T08:33:11Z" level=info msg="setting quiet times" daysOfYear="[]" timesOfDay="[]" weekdays="[]"time="2020-09-01T08:33:11Z" level=info msg="setting timezone" location=UTC name=UTC offset=0time="2020-09-01T08:33:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-8kf64 namespace=test-monkeystime="2020-09-01T08:43:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-t7wx7 namespace=test-monkeystime="2020-09-01T08:53:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-8fg9q namespace=test-monkeystime="2020-09-01T09:03:11Z" level=info msg="terminating pod" name=nginx-594cc45b78-wf5vg namespace=test-monkeys

Конфигурировать можно всё, что может потребоваться: часовой пояс, временные исключения, лейблы, по которым ищутся pod'ы-жертвы, и исключения.

Подводя быстрый итог: хороший, удобный и простой инструмент, но, как и kube-monkey, умеет только убивать pod'ы.

3. Chaos Mesh

GitHub: https://github.com/chaos-mesh/chaos-mesh
Звёзды / контрибьюторы: 2400 / 50+
Язык: Go

Chaos Mesh состоит из двух компонентов:

Chaos Operator оператор хаоса, основной компонент, который в свою очередь состоит из:
1. controller-manager (управляет Custom Resources),
2. chaos-daemon (привилегированный daemonset с возможностями управления сетью, cgroups и т.д.),
3. sidecar-контейнера, динамически вставляемогов целевой pod, чтобы вмешиваться в I/O целевого приложения.
Chaos Dashboard веб-интерфейс для управления и мониторинга хаос-оператора

Проект входит в CNCF и разработан китайской компанией PingCAP, которая известна своей распределённой, Open Source, cloud-native SQL-базой данных для аналитики в реальном времени TiDB (мы писали про её собрата TiKV, тоже входящего в число проектов CNCF).

Итак, хаос-оператор использует CRD для определения объектов хаоса. Всего их шесть типов: PodChaos, NetworkChaos, IOChaos, TimeChaos, StressChaos и KernelChaos. А вот какие доступны действия (эксперименты):

pod-kill убийство pod'а;
pod-failure недоступность pod'а некоторое (определённое) время;
container-kill убийство одного из контейнеров pod'а;
netem chaos сетевые проблемы, задержки, повторы пакетов;
network-partition эмуляция распада сети на сегменты;
IO chaos проблемы с диском и чтением/записью;
time chaos искажение показателя текущего времени в pod'е;
cpu-burn стресс CPU;
memory-burn стресс памяти;
kernel chaos жертва получит ошибки ядра, фрагментацию страниц памяти, проблемы с блочным I/O.

Объявляя любой из нужных нам Custom Resource, мы можем указать в нём типы действий, лейблы и селекторы для определения целевых namespace или конкретных pod'ов, а также длительность и расписание проведения экспериментов в общем, всё необходимое для планирования веселья.
Звучит очень интересно, да? Давайте попробуем! Документация по установке снова с Helm.

Не забудем указать --set dashboard.create=true, чтобы получить панели с красивыми графиками! Через пару минут мы получаем целое пространство имён из повелителей хаоса пока ещё бездействующих, но уже готовых к работе:

$ kubectl -n chaos-testing get poNAME                                       READY   STATUS    RESTARTS   AGEchaos-controller-manager-bb67cb68f-qpmvf   1/1     Running   0          68schaos-daemon-krqsh                         1/1     Running   0          68schaos-daemon-sk7qf                         1/1     Running   0          68schaos-daemon-wn9sd                         1/1     Running   0          68schaos-dashboard-7bd8896c7d-t94pt           1/1     Running   0          68s

Для изучения и демонстрации работы chaos-mesh подготовлен подробный мануал, в котором можно увидеть многочисленные возможности оператора. С технической точки зрения, внутри репозитория (https://github.com/chaos-mesh/web-show) находится Deployment тестового приложения на React с сервисом, которому скриптом передаётся IP-адрес pod'а kube-controller-manager (первый из списка, если у нас мультимастер, или просто единственный). После запуска этот pod начинает непрерывно пинговать pod controller-manager'а и визуализировать на графике этот ping.

В нашем случае удобнее выпустить этот график наружу через Ingress, а не команду из deploy.sh (

nohup kubectl
port-forward svc/web-show --address 0.0.0.0 8081:8081

). Поэтому мы просто применяем Deployment и Service из репозитория и объявляем любой Ingress просто для того, чтобы можно было попасть в приложение снаружи.

Приятный график. Судя по сегменту ST, у пациента острый инфаркт! Стоп, это же не кардиограмма А теперь можно применить заклинание хаоса, слегка подкорректировав его для пущей красоты:

apiVersion: chaos-mesh.org/v1alpha1kind: NetworkChaosmetadata:  name: web-show-network-delayspec:  action: delay # the specific chaos action to inject  mode: one # the mode to run chaos action; supported modes are one/all/fixed/fixed-percent/random-max-percent  selector: # pods where to inject chaos actions    namespaces:      - test-monkeys    labelSelectors:      "app": "web-show"  # the label of the pod for chaos injection  delay:    latency: "50ms"  duration: "10s" # duration for the injected chaos experiment  scheduler: # scheduler rules for the running time of the chaos experiments about pods.    cron: "@every 60s"

Результат ожидаемая нами красивая пила, сигнализирующая о том, что netem chaos уже работает. И вот тут уже точно инфаркт.

А вот как выглядит chaos-dashboard:

Визуализация событий:

Подробности о конкретном эксперименте:

Есть даже веб-редактор Custom Resources, но встроенной авторизации к нему нет (обязательно надо закрывать авторизацией!):

В завершении обзора этого проекта стоит упомянуть, что недавно (25 сентября 2020 г.) у Chaos Mesh произошло знаменательное событие релиз версии 1.0.

Продолжение следует

Во второй части статьи будут рассмотрены Litmus Chaos, Chaos Toolkit, игровые варианты хаос-инжиниринга в Kubernetes и некоторые другие проекты, а также подведён общий итог.

P.S.

Читайте также в нашем блоге:

Chaos Engineering: искусство умышленного разрушения. Часть 1 (про концепцию chaos engineering и как он помогает находить/исправлять проблемы до того, как они приведут к сбоям production);
Chaos Engineering: искусство умышленного разрушения. Часть 2 (как chaos engineering способствует позитивным культурным изменениям внутри организаций);
Chaos Engineering: искусство умышленного разрушения. Часть 3 (практика chaos engineering с внесением неисправностей и существующими для этого инструментами).