Инженерия хаоса с Litmus: проект в инкубаторе CNCF

Постановка проблемы: Обеспечение устойчивости платформы электронной коммерции на основе микросервисов.

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

Организация планирует использовать проект Litmus, разработанный CNCF, для проведения оценок и улучшения устойчивости платформы. Наши уязвимые точки системы становятся яснее, когда мы проводим симулированные тесты сбоев с использованием Litmus, что позволяет нам вызывать реальные ситуации сбоев, такие как события завершения подов и задержки в сети, а также ограничения использования ресурсов. Эксперименты позволяют нам проверить системы автоматизации масштабирования и протестировать процедуры восстановления после катастрофы, а также оптимизировать настройки Kubernetes для обеспечения общей надежности системы.

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

Настройте среду для экспериментов с хаосом

Установите LitmusChaos на свой кластер Kubernetes:

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/

helm repo update

helm install litmus litmuschaos/litmus

Проверьте установку:

kubectl get pods -n litmus

Примечание: убедитесь, что ваш кластер готов к хаос-экспериментам.

Определите эксперимент хаоса

Создайте файл YAML ChaosExperiment для моделирования сценария удаления Pod

Пример (pod-delete.yaml):

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosExperiment

metadata:

  name: pod-delete

  namespace: litmus

spec:

  definition:

    scope: Namespaced

    permissions:

      - apiGroups: ["*"]

        resources: ["*"]

        verbs: ["*"]

    image: "litmuschaos/go-runner:latest"

    args:

      - -c

      - ./experiments/generic/pod_delete/pod_delete.test

    command:

      - /bin/bash

Установите ChaosOperator и настройте учетную запись службы

Разверните ChaosOperator для управления экспериментами:

kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-operator/cluster-k8s.yml

Примечание: создайте учетную запись службы для предоставления необходимых разрешений.

Внедрите хаос в целевое приложение

Отметьте пространство имен приложения для хаоса:

kubectl label namespace <target-namespace> litmuschaos.io/chaos=enabled

Разверните ChaosEngine для запуска эксперимента:

Пример (chaosengine.yaml):

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosEngine

metadata:

  name: pod-delete-engine

  namespace: <target-namespace>

spec:

  appinfo:

    appns: '<target-namespace>'

    applabel: 'app=<your-app-label>'

    appkind: 'deployment'

  chaosServiceAccount: litmus-admin

  monitoring: false

  experiments:

    - name: pod-delete

Примените ChaosEngine:

kubectl apply -f chaosengine.yaml

Отслеживайте эксперимент

Просмотрите прогресс:

kubectl describe chaosengine pod-delete-engine -n <target-namespace>

Проверьте статус хаос-подов:

kubectl get pods -n <target-namespace>

Проанализируйте результаты

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

Вот некоторые метрики для мониторинга:

• Время ответа приложения
• Коэффициент ошибок во время и после эксперимента
• Время восстановления подов

Решение

Выявлен корень проблемы: Во время высокой загрузки поды не справились из-за недостаточного числа реплик в развертывании и неправильных лимитов ресурсов.

Примененные исправления:

• Увеличено количество реплик в развертывании для обработки высокой загрузки
• Настроены правильные запросы и лимиты ресурсов для ЦП и памяти в спецификации пода
• Реализован горизонтальный масштабировщик подов (HPA) для динамической обработки всплесков трафика

Заключение

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