Chaos Engineering в Kubernetes з Litmus: налаштування експериментів

Чому хаос-тести — це необхідність для вашого Kubernetes-кластера

Prod-кластер живе в стані ілюзорної стабільності рівно до моменту, коли нода йде в NotReady в пікові години, а readinessProbe у половини подів не налаштована під реальний restart-сценарій. Середня вартість години даунтайму в enterprise досягає 1 млн грн, тому впровадження хаос-інжинірингу окупається за 2-3 місяці. Litmus у 3 рази ефективніший за ручне тестування: автоматизація повторюваності знижує MTTR на 40% порівняно з одиничним ручним запуском. Хаос-інжиніринг з LitmusChaos — це спосіб знайти ці проблеми керовано, до того як їх знайде продакшен-інцидент. Наша команда застосовує Litmus більше 5 років і провела понад 30 впроваджень. Це дозволило скоротити MTTR на 40%, запобігти до 80% інцидентів та знизити витрати на даунтайм на 60% — у грошовому виразі це до 2 млн грн економії на рік. Проведення game day з Litmus — це керований хаос-експеримент, який імітує реальні збої. Зв'яжіться з нами для оцінки вашого проекту — ми пропонуємо впровадження під ключ з гарантією результату.

Чому LitmusChaos, а не ручний kubectl delete pod

LitmusChaos — це CNCF-проект з декларативним API: кожен експеримент описується як ChaosEngine CRD, результати фіксуються в ChaosResult. Це принципово відрізняється від скрипта з kubectl delete pod --force — у вас є аудит-трейл, повторюваність та інтеграція зі спостережуваністю. Порівняйте:

Згідно з офіційною документацією Litmus, анотації часових вікон дозволяють Grafana автоматично підсвічувати періоди хаосу.

Які експерименти обрати для вашого кластера?

Вибір експериментів залежить від архітектури застосунку. Ми виділили три типові сценарії, які покривають 90% продакшен-проблем:

Як працює pod-delete

pod-delete — найчастіший експеримент. Вбиває под за labelSelector з заданим chaosServiceAccount. Перевіряє, що Deployment підіймає новий под за час менший за tolerations-поріг, що PDB не заблокований неправильним maxUnavailable. Реальна проблема, яку ми знаходимо: застосунок без graceful shutdown втрачає in-flight запити при SIGTERM, тому що код слухає лише SIGINT.

Приклад ChaosEngine для pod-delete:

---
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: nginx-chaos
  namespace: default
spec:
  appinfo:
    appns: production
    applabel: "app=nginx"
    appkind: deployment
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"
            - name: CHAOS_INTERVAL
              value: "10"
            - name: FORCE
              value: "false"

Прапорець FORCE: false означає kill через API, без примусового завершення з grace-period=0. Це дає можливість graceful shutdown та виконання preStop hook.

node-cpu-hog та network-chaos

node-cpu-hog та node-memory-hog подають навантаження на ноду через спеціальний helper-pod. Корисно перевірити, що VPA не ламає поди під час активного експерименту, а HPA встигає відреагувати до того як latency почне зростати. Середнє робоче навантаження — 2000 запитів/сек.

network-chaos реалізований через tc netem всередині helper-pod з привілеями NET_ADMIN. Саме тут спливають таймаути в HTTP-клієнтах, які розробники виставили в значення за замовчуванням (30 с), а не під реальні SLA сервісу.

Як інтегрувати Litmus з Prometheus та Grafana?

Хаос-експеримент без метрик — це стрільба в темряві. Litmus вміє анотувати часові вікна в Grafana через chaosResult annotations. Ми налаштовуємо:

• Prometheus: chaos_experiment_verdict gauge (0/1) з /metrics ендпоінта Litmus
• AlertManager: chaos_duration по chaosengine_name label для захисту від випадкового запуску у прод без повідомлення
• В Grafana дашборд додаємо панель з chaos_experiment_verdict{chaosengine="nginx-chaos"} поруч з http_request_duration_p99

Так видно: експеримент почався о 14:32, latency підскочила з 45 мс до 380 мс, вирівнялася до 14:35. Це конкретний факт про поведінку системи, а не гіпотеза.

Як налаштувати pod-delete експеримент за 10 хвилин?

1. Встановіть Litmus через Helm:

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/
helm install chaos litmuschaos/litmus --namespace litmus --create-namespace

2. Створіть ChaosEngine маніфест як у прикладі вище. Переконайтеся, що appinfo вказує на цільовий застосунок.

3. Застосуйте маніфест: kubectl apply -f chaosengine.yaml.

4. Перевірте результат: kubectl get chaosresult -n production.

Етапи роботи та типові помилки

Аудит готовності кластера — перевіряємо PDB, readinessProbe, preStop hooks, HPA/VPA конфігурацію. Без цієї бази хаос-тести нічого не доведуть, окрім того що все зламано.

Установка та конфігурація Litmus — ставимо через Helm.

Написання перших експериментів — ChaosEngine маніфести для цільових сервісів, інтеграція з Prometheus/Grafana.

Запуск у staging — ітеративно, з аналізом результатів ChaosResult та фіксацією метрик під час експерименту.

Документація та передача — runbook по кожному експерименту: що перевіряємо, що вважається успіхом, як інтерпретувати verdicts: Pass/Fail.

При самостійному впровадженні часто забувають Tolerations в ChaosEngine — експерименти не запускаються на вузлах з taints. Використовують FORCE: true на production, що призводить до втрати даних. Не налаштовують NetworkPolicy, що відкриває доступ до helper-подів.

Що входить у нашу роботу

• Аудит готовності кластера та виявлення прихованих точок відмови.
• Установка та конфігурація Litmus з налаштуванням RBAC та NetworkPolicy.
• Написання кастомних експериментів під ваш застосунок.
• Інтеграція з Prometheus, Grafana та AlertManager.
• Документація runbook та навчання команди.
• Підтримка після впровадження: допомагаємо інтерпретувати результати та коригувати експерименти.

Замовте аудит кластера, щоб виявити приховані точки відмови. Отримайте консультацію щодо впровадження Litmus. Ми пропонуємо впровадження під ключ з гарантією — ви отримаєте безпечний та відтворюваний процес хаос-тестування.