Создание более устойчивого Apache APISIX Ingress Controller с использованием Litmus Chaos

Обзор

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

Зачем нужна инженерия хаоса?

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

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

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

1. Введение разрушительных событий

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

2. Проверка устойчивости системы

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

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

3. Обнаружение скрытых проблем

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

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

4. Что это стоит и зачем это нужно?

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

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

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

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

Как проектировать эксперименты хаоса для Ingress-контроллера?

1. Что такое Ingress?

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

2. Что такое Ingress-контроллер?

Ресурс Ingress требует Ingress-контроллера для его обработки. Контроллер преобразует правила Ingress в конфигурации на прокси, позволяя внешним клиентам получать доступ к сервисам внутри кластера. В производственной среде Ingress-контроллеры должны обладать сложными возможностями, такими как ограничение источников доступа и методов запросов, аутентификация и авторизация. Большинство Ingress-контроллеров расширяют семантику Ingress через аннотации в ресурсе Ingress.

3. Что такое Apache APISIX Ingress Controller?

Apache APISIX Ingress Controller — это специализированный тип балансировщика нагрузки, который помогает администраторам управлять и контролировать трафик Ingress. Он использует APISIX в качестве плоскости данных, чтобы предоставить пользователям динамическую маршрутизацию, балансировку нагрузки, эластичное масштабирование, политики безопасности и другие функции для улучшения контроля над сетью и обеспечения более высокой доступности и безопасности для их бизнеса. APISIX Ingress Controller поддерживает три режима конфигурации: Kubernetes Ingress, пользовательские ресурсы и Gateway API.

4. Что такое Litmus Chaos?

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

5. Как проектировать эксперименты хаоса?

Вот общая процедура для проектирования экспериментов хаоса в любом сценарии:

• Определите тестируемую систему: Определите конкретные компоненты системы, на которых вы хотите провести эксперимент, и разработайте четкие и измеримые цели для эксперимента. Это включает создание полного списка компонентов, таких как аппаратное и программное обеспечение, которые будут тестироваться, а также определение объема эксперимента и ожидаемых результатов.

kube-apiserver: если возникает исключение, запись ресурса Ingress не удалась. Ingress-controller: Сбой сети, Crash, Podfaults, I/O data-plane: Сбой сети, Crash, Podfaults, I/O

• Выберите подходящий эксперимент: Выберите эксперимент, который соответствует поставленным целям и максимально приближен к реальному сценарию. Это поможет убедиться, что эксперимент даст значимые результаты и точно отразит поведение системы.
• Установите гипотезу: Установите гипотезу о том, как система будет вести себя во время эксперимента и каких результатов вы ожидаете. Это должно быть основано на опыте или исследованиях, и гипотеза должна быть разумной и проверяемой.
• Проведите эксперимент: Проведите эксперимент в контролируемой среде, такой как тестовая среда, чтобы ограничить потенциальный вред для производственной системы. Соберите все соответствующие данные во время эксперимента и сохраните их безопасно. Могут быть разные мнения о том, должен ли эксперимент проводиться непосредственно в производственной среде. Однако для большинства сценариев нам нужно убедиться, что целевой уровень обслуживания (SLO) системы соблюдается.
• Оцените результаты: Оцените результаты эксперимента и сравните их с вашей гипотезой. Проанализируйте собранные данные и задокументируйте любые наблюдения или выводы. Это включает выявление любых неожиданных результатов или расхождений и определение того, как они могут повлиять на систему. Кроме того, подумайте, как результаты эксперимента могут быть использованы для улучшения системы.

Основные сценарии использования Ingress-контроллера

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

Чтобы определить тестируемую систему для APISIX Ingress Controller, пользователям необходимо создать конфигурации маршрутов, такие как Ingress, Gateway API или CRD, и применить их к кластеру Kubernetes через Kubectl. Этот процесс проходит через kube-apiserver для аутентификации, авторизации, допуска и других связанных процедур, а затем сохраняется в etcd.

APISIX Ingress Controller постоянно отслеживает изменения в ресурсах Kubernetes. Эти конфигурации затем преобразуются в конфигурации на плоскости данных. Когда клиент запрашивает плоскость данных, она обращается к вышестоящему сервису в соответствии с правилами маршрутизации.

Если kube-apiserver выходит из строя, это предотвратит создание конфигурации или получение правильной конфигурации Ingress-контроллером. Аналогично, если возникает сбой на плоскости данных, такой как сбой сети или завершение работы Pod, это также не позволит нормально проксировать трафик.

Область нашего эксперимента в основном касается влияния на доступность системы, если Ingress-контроллер выходит из строя.

1. Подробные шаги выполнения

• Выберите подходящий эксперимент: Мы можем охватить множество сценариев неправильной конфигурации с помощью сквозных тестов. В основном с помощью инженерии хаоса мы можем проверить, может ли плоскость данных по-прежнему проксировать трафик нормально, когда Ingress-контроллер сталкивается с исключением, таким как ошибки DNS, сбои сети или завершение работы Pod.
• Установите гипотезу: Для каждого сценария мы можем создать гипотезу, например: "Когда Pod Ingress-controller получает X?, запрос клиента все еще может получить нормальный ответ."
• Проведите эксперимент: Эксперимент и переменные уже определены, так что все, что осталось, — это провести эксперимент.
  Litmus Chaos предоставляет различные способы проведения экспериментов. Мы можем сделать это через Litmus Portal. Для этого нам нужно создать сценарий хаоса, выбрать приложение для эксперимента, и эти шаги относительно просты. Однако мы должны обратить внимание на то, что Litmus Chaos включает ресурс Probes.

Probes — это подключаемые проверки, которые могут быть определены в ChaosEngine для любого эксперимента хаоса. Экспериментальные Pod выполняют эти проверки в зависимости от режима, в котором они определены, и учитывают их успех как необходимые условия для определения вердикта эксперимента, в дополнение к стандартным встроенным проверкам. В то же время мы также можем планировать эксперименты, что является очень ценной функцией.

Кроме того, Litmus Chaos также поддерживает проведение экспериментов путем отправки YAML-манифестов.

• Оцените результаты: Litmus Chaos имеет встроенные статистические отчеты, и он может быть интегрирован с Prometheus и Grafana для предоставления единой панели управления для интеграции.

2. Преимущества и будущее

Благодаря тщательным сквозным тестам и силе инженерии хаоса, мы уверены в стабильности и надежности предоставляемого APISIX Ingress Controller. Инженерия хаоса также помогла нам выявить и исправить ошибки. Мы постоянно работаем над улучшением и развитием этого удивительного проекта, и мы приглашаем вас присоединиться к нашему сообществу.