Поделиться через

Развертывание и тестирование критически важных рабочих нагрузок в Azure

  • Статья

Развертывание и тестирование критически важной среды является важной частью общей эталонной архитектуры. Отдельные метки приложений развертываются с помощью инфраструктуры в качестве кода из репозитория исходного кода. Обновления инфраструктуры и приложения наверху должны быть развернуты с нулевым временем простоя в приложении. Рекомендуется использование потока непрерывной интеграции DevOps для получения исходного кода из репозитория и развертывания отдельных компонентов в Azure.

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

Новые штампы добавляются в Azure Front Door. Трафик постепенно перемещается на новые метки. Когда трафик обслуживается из новых меток без проблем, предыдущие метки удаляются.

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

Развёртывание

Развертывание инфраструктуры в эталонной архитектуре зависит от следующих процессов и компонентов:

  • DevOps — исходный код из GitHub и конвейеров для инфраструктуры.

  • Обновления без простоя. Обновления и апгрейды развертываются в среде с нулевым временем простоя для развернутого приложения.

  • Окружения — кратковременные и постоянные окружения, используемые для архитектуры.

  • общие и выделенные ресурсы — ресурсы Azure, которые выделены и разделены для кластеров и общей инфраструктуры.

схема блок-схемы процесса развертывания.

Дополнительные сведения см. в статье Развертывание и тестирование критически важных рабочих нагрузок в Azure. Рекомендации по проектированию

Развертывание: DevOps

Компоненты DevOps предоставляют репозиторий исходного кода и конвейеры CI/CD для развертывания инфраструктуры и обновлений. GitHub и Azure Pipelines были выбраны в качестве компонентов.

  • GitHub — содержит репозитории исходного кода для приложения и инфраструктуры.

  • Azure Pipelines — конвейеры, используемые архитектурой для всех задач сборки, тестирования и выпуска.

Дополнительный компонент в проектировании, используемый для развертывания, — агенты сборки. Агенты сборки, предоставляемые Microsoft, используются в составе Azure Pipelines для развертывания инфраструктуры и обновлений. Использование агентов сборки, хостящихся в Microsoft, уменьшает объем управленческой нагрузки для разработчиков, связанный с агентом сборки.

Дополнительные сведения о Azure Pipelines см. в статье Что такое Azure Pipelines?.

схема блок-схемы конвейера DevOps.

Дополнительные сведения см. в статье Развертывание и тестирование критически важных рабочих нагрузок в Azure: развертывания инфраструктуры как кода

Развертывание: обновления без простоя

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

Существует два основных компонента эталонной архитектуры:

  • Инфраструктура - службы и ресурсы Azure. Развернутые с помощью Terraform и связанной с ней конфигурации.

  • приложения — хостинговая служба или приложение, которое обслуживает пользователей. Основано на контейнерах Docker и созданных с помощью npm артефактах в HTML и JavaScript для пользовательского интерфейса одностраничного приложения (SPA).

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

  • единый процесс — меньше шансов на ошибки, если обновления инфраструктуры и приложений смешиваются в выпуске, намеренно или нет.

  • включает развертывания Blue/Green, при котором каждое обновление осуществляется через постепенное перенаправление трафика на новый выпуск.

  • Упрощение развертывания и отладки приложения. Вся метка никогда не размещает несколько версий приложения параллельно.

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

  • устранение изменений вручную и смещения конфигурации. Каждая среда — это новое развертывание.

Дополнительные сведения см. в статье Развертывание и тестирование критически важных рабочих нагрузок в Azure: эфемерные сине-зеленые развертывания

Стратегия ветвления

Основой стратегии обновления является использование ветвей в репозитории Git. Эталонная архитектура использует три типа ветвей:

Ветка Описание
feature/* и fix/* Точки входа для любых изменений. Разработчики создают эти ветви и должны иметь описательное имя, например feature/catalog-update или fix/worker-timeout-bug. Когда изменения будут готовы к слиянию, создается запрос на вытягивание (PR) для ветви main. По крайней мере один рецензент должен утвердить все pull-запросы. За редкими исключениями каждое изменение, предлагаемое в PR, должно проходить через конвейер проверки (E2E). Разработчики должны использовать конвейер E2E для тестирования и отладки изменений в полной среде.
main Непрерывно продвигающаяся и стабильная ветвь. В основном используется для тестирования интеграции. Изменения в main вносятся только через пулы запросов. Политика ветви запрещает прямые записи. Ночные выпуски для постоянной среды integration (int) автоматически выполняются из ветви main. Ветвь main считается стабильной. Можно с уверенностью предположить, что в любой момент времени из него можно создать выпуск.
release/* Ветви выпуска создаются только из ветви main. Формат ветвей соответствует release/2021.7.X. Политики ветви используются так, что только администраторы репозитория могут создавать ветвь release/*. Для развертывания в среде prod используются только эти ветви.

Дополнительные сведения см. в статье Развертывание и тестирование критически важных рабочих нагрузок в Azure: стратегия ветвления

Исправления

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

Исправление должно быть создано в новой ветви fix, а затем объединиться в main с помощью обычного PR. Вместо создания новой ветви выпуска исправление "вишневое" выбирается в существующую ветвь выпуска. Эта ветвь уже развернута в среде prod. Конвейер CI/CD, который изначально развернул релизную ветку с тестами, выполняется снова и разворачивает горячее исправление как часть конвейера.

Чтобы избежать серьёзных проблем, важно, чтобы хотфикс содержал несколько изолированных коммитов, которые можно легко черри-пикнуть и интегрировать в релизную ветвь. Если изолированные фиксации не могут быть перенесены для интеграции в ветвь релиза, это свидетельствует о том, что изменение не является экстренным исправлением. Разверните изменение как полный релиз. Объедините это с откатом к предыдущей стабильной версии до тех пор, пока новый релиз не будет развернут.

Развертывание: среды

Эталонная архитектура использует два типа сред для инфраструктуры:

  • кратковременные. Пиплайн валидации E2E используется для развертывания кратковременных сред. Кратковременные среды используются для чистой проверки или отладки сред для разработчиков. Среды проверки можно создать из ветви feature/*, подвергнуть тестам, а затем уничтожить, если все тесты были успешными. Среды отладки развертываются так же, как и проверка, но не уничтожаются немедленно. Эти среды не должны существовать в течение нескольких дней и должны быть удалены при слиянии соответствующего PR ветви компонентов.

  • постоянный - В перманентных окружениях существуют версии integration (int) и production (prod). Эти среды существуют постоянно и не разрушаются. В средах используются фиксированные доменные имена, такие как int.mission-critical.app. В реальной реализации эталонной архитектуры необходимо добавить среду staging (предпродакшен). Среда staging используется для развертывания и проверки ветвей release с таким же процессом обновления, как и у prod (синее/зеленое развертывание).

    • Integration (int) — версия int развертывается каждую ночь из ветви main с тем же процессом, что и prod. Переключение трафика происходит быстрее, чем в предыдущей версии. Вместо того чтобы переключать трафик постепенно в течение нескольких дней, как это происходит в prod, процесс int завершается в течение нескольких минут или часов. Это быстрое переключение гарантирует, что обновленная среда готова к следующему утром. Старые метки автоматически удаляются, если все тесты в конвейере успешны.

    • Production (prod) — версия prod развертывается только из ветвей release/*. Переключение трафика использует более детализированные шаги. Между каждым шагом находится ручной контрольный пункт. Каждое издание создает новые региональные стемпы и развертывает новую версию приложения на эти стемпы. Существующие метки не затрагиваются в процессе. Наиболее важным аспектом prod является то, что оно должно быть "всегда включено". Никогда не должно возникать плановое или незапланированное время простоя. Единственным исключением является базовое изменение уровня базы данных. Возможно, потребуется запланированное время обслуживания.

Развертывание: общие и выделенные ресурсы

Постоянные среды (int и prod) в эталонной архитектуре имеют разные типы ресурсов в зависимости от того, используются ли они совместно со всей инфраструктурой или выделенной отдельной меткой. Ресурсы могут быть выделены для конкретного выпуска и будут существовать только до тех пор, пока следующая единица выпуска не перейдет.

Единицы выпуска

Единица выпуска — это несколько региональных меток для конкретной версии выпуска. Штампы содержат все ресурсы, которые не разделяют с другими штампами. Эти ресурсы — это виртуальные сети, кластер службы Azure Kubernetes, центры событий и Azure Key Vault. Azure Cosmos DB и ACR настроены с источниками данных Terraform.

Глобальные общие ресурсы

Все ресурсы, совместно используемые между единицами выпуска, определяются в независимом шаблоне Terraform. Эти ресурсы : Front Door, Azure Cosmos DB, реестр контейнеров (ACR) и рабочие области Log Analytics и другие ресурсы, связанные с мониторингом. Эти ресурсы развертываются до развертывания первой региональной отметки релизной единицы. Ресурсы упоминаются в шаблонах Terraform для штампов.

Входная дверь

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

Конфигурацию серверной части Front Door нельзя напрямую определить в шаблоне Terraform. Конфигурация вставляется с помощью переменных Terraform. Значения переменной создаются до запуска развертывания Terraform.

Конфигурация отдельных компонентов для развертывания Front Door определена как:

  • фронтенд — настроено закрепление сеансов, чтобы пользователи не переключались между разными версиями UI в течение одной сессии.

  • Источники — Front Door настроен с двумя типами групп источников:

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

    2. Группа источников для API, размещенная в службе Azure Kubernetes. Если существуют единицы выпуска с различными версиями API, то для каждого модуля выпуска существует группа источников API. Если все единицы выпуска предлагают один и тот же совместимый API, все источники добавляются в одну группу и назначаются разные весовые значения.

  • правила маршрутизации. Существует два типа правил маршрутизации:

    1. Правило маршрутизации для UI, связанное с группой источников хранения UI.

    2. Правило маршрутизации для каждого API, поддерживаемого источником. Например, /api/1.0/* и /api/2.0/*.

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

Развертывание: процесс развертывания

Цель процесса развертывания — это сине-зеленое развертывание. Новый релиз из ветви release/* внедряется в среду prod. Трафик пользователей постепенно перенаправляется на метки для нового релиза.

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

После развертывания и проверки нового модуля новый модуль добавляется в "Front Door" для обработки пользовательского трафика.

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

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

Разбор выпускного узла

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

Контрольные списки

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

  • контрольный список перед выпуском — Перед началом выпуска проверьте следующее:

    • Убедитесь, что последнее состояние ветви main успешно развернуто и проверено в среде int.

    • Обновите файл журнала изменений с помощью запроса на main ветвь.

    • Создайте ветвь release/ из ветви main.

  • Послерелизный Контрольный список - Перед тем как старые метки будут уничтожены и их ссылки удалены из Front Door, убедитесь, что:

    • Кластеры больше не получают входящий трафик.

    • Центры событий и другие очереди сообщений не содержат необработанных сообщений.

Развертывание: ограничения и риски стратегии обновления

Стратегия обновления, описанная в этой эталонной архитектуре, имеет некоторые ограничения и риски, которые следует упомянуть:

  • Более высокая стоимость. При выпуске обновлений многие компоненты инфраструктуры активируются дважды в течение периода выпуска.

  • Сложность Front Door — процесс обновления в Front Door является сложным для реализации и обслуживания. Возможность выполнения эффективных сине-зеленых развертываний с нулевым временем простоя зависит от его правильной работы.

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

Развертывание. Рекомендации по совместимости пересылки данных приложений

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

Тестирование

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

К этим тестам относятся следующие:

  • модульные тесты. Эти тесты проверяют, работает ли бизнес-логика приложения должным образом. Эталонная архитектура содержит пример набора модульных тестов, выполняемых автоматически перед каждой сборкой контейнера Azure Pipelines. Если какой-либо тест завершается ошибкой, конвейер останавливается. Сборка и развертывание останавливается. Разработчик должен устранить проблему, прежде чем конвейер можно будет выполнить снова.

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

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

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

  • тесты внедрения сбоев. Эти тесты можно автоматизировать или выполнять вручную. Автоматическое тестирование в архитектуре включает Azure Chaos Studio в рамках потоков развертывания.

Дополнительные сведения см. в статье Развертывание и тестирование критически важных рабочих нагрузок в Azure: непрерывная проверка и тестирование

Тестирование: фреймворки

Онлайн-эталонная реализация существующих возможностей тестирования и платформ по возможности.

Каркас Тест Описание
NUnit Единица Эта платформа используется для модульного тестирования части реализации .NET Core. Azure Pipelines выполняет модульные тесты автоматически перед сборками контейнеров.
JMeter в нагрузочном тестировании Azure Загрузка Нагрузочное тестирование Azure — это управляемая служба, используемая для выполнения определений нагрузочных тестов Apache JMeter.
Саранча Загрузка Locust — это платформа нагрузочного тестирования с открытым исходным кодом, написанная на Python.
драматург Пользовательский интерфейс и дым Playwright — это библиотека с открытым кодом Node.js для автоматизации Chromium, Firefox и WebKit с помощью одного API. Определение теста Playwright также можно использовать независимо от эталонной реализации.
Azure Chaos Studio Внедрение ошибок Эталонная реализация использует Azure Chaos Studio в качестве дополнительного шага в конвейере проверки E2E для внедрения сбоев для проверки устойчивости.

Тестирование: инъекция отказов и инжиниринг хаоса

Распределенные приложения должны быть устойчивыми к сбоям служб и компонентов. Тестирование с инъекцией отказов (также известное как введение ошибок или инженерия хаоса) — это практика подвергания приложений и служб реальным стрессам и отказам.

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

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

Автоматически

Эталонная архитектура интегрируется Azure Chaos Studio для развертывания и запуска набора экспериментов Azure Chaos Studio для внедрения различных ошибок на уровне метки. Эксперименты хаоса можно выполнять как необязательную часть конвейера развертывания E2E. При выполнении тестов необязательный нагрузочный тест всегда выполняется параллельно. Нагрузочный тест используется для создания нагрузки в кластере для проверки влияния внедренных сбоев.

Вручную

Тестирование внедрения ошибок вручную должно выполняться в среде проверки E2E. Эта среда обеспечивает полные репрезентативные тесты без риска вмешательства из других сред. Большинство сбоев, вызванных тестами, можно наблюдать непосредственно в представлении живых метрик Application Insights. Остальные сбои доступны в представлении сбоев и соответствующих таблицах журналов. Другие сбои требуют более глубокой отладки, например использования kubectl для наблюдения за поведением в службе Azure Kubernetes.

Приведены два примера тестов внедрения сбоев, выполняемых против эталонной архитектуры:

  • DNS (Служба доменных Имен), основанный на инъекции сбоев — тестовый случай, который может имитировать несколько проблем. Сбои разрешения DNS, вызванные либо отказом DNS-сервера, либо Azure DNS. Тестирование на основе DNS может помочь имитировать общие проблемы подключений между клиентом и службой, например если BackgroundProcessor не удается подключиться к центрам событий.

    В сценариях с одним узлом можно изменить локальный hosts-файл, чтобы перезаписать разрешение DNS. В более крупной среде с несколькими динамическими серверами, такими как АКС, использование файла hosts невозможно. частные зоны DNS Azure можно использовать в качестве альтернативы сценариям тестирования сбоев.

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

  • блокировка брандмауэра. Большинство служб Azure поддерживают ограничения доступа к брандмауэру на основе виртуальных сетей и (или) IP-адресов. В эталонной инфраструктуре эти ограничения используются для ограничения доступа к Azure Cosmos DB или Центрам событий. Простая процедура заключается в удалении существующих правил Разрешить или добавлении новых правил Блокировать. Эта процедура может имитировать неправильные настройки брандмауэра или сбоя служб.

    Следующие примеры служб в эталонной реализации можно протестировать с помощью теста брандмауэра:

    Служба Результат
    Key Vault Когда доступ к Key Vault заблокирован, непосредственным следствием будет сбой в создании новых подов. Драйвер CSI Key Vault, который получает секреты при запуске pod, не может выполнять свои задачи и предотвращает запуск pod. Соответствующие сообщения об ошибках можно наблюдать при kubectl describe po CatalogService-deploy-my-new-pod -n workload. Существующие модули pod продолжают работать, хотя наблюдается то же сообщение об ошибке. Итоги периодической проверки секретов вызывают сообщение об ошибке. Хотя это не было проверено, выполнение развертывания невозможно, пока Key Vault недоступен. Задачи Terraform и Azure CLI в ходе выполнения конвейера выполняют запросы к Key Vault.
    Event Hubs центр событий При блокировке доступа к Центрам событий новые сообщения, отправленные catalogService и HealthService, завершаются ошибкой. Получение сообщений с помощью BackgroundProcess медленно терпит неудачу, заканчиваясь полным сбоем в течение нескольких минут.
    Azure Cosmos DB Удаление существующей политики брандмауэра для виртуальной сети приводит к сбою службы работоспособности с минимальным задержкой. Эта процедура имитирует только конкретный случай, весь сбой Azure Cosmos DB. Большинство случаев сбоя, возникающих на региональном уровне, устраняются автоматически благодаря прозрачной переадресации клиента в другой регион Azure Cosmos DB. Ранее описанное тестирование имитации отказов на основе DNS является более значимым тестом для Azure Cosmos DB.
    Реестр контейнеров (ACR) Когда доступ к ACR заблокирован, создание новых подов, которые ранее были извлечены и кэшированы на узле AKS, продолжает работать. Создание по-прежнему работает благодаря флагу развертывания pullPolicy=IfNotPresentдля K8s. Узлы не могут создать новый pod и немедленно завершаются с ошибкой ErrImagePull, если узел не загружает и не кэширует образ перед блокировкой. kubectl describe pod отображает соответствующее сообщение 403 Forbidden.
    входящего трафика AKS Load Balancer Изменение входящих правил для HTTP(S) (портов 80 и 443) в управляемой AKS группой безопасности сети (NSG) на запретить приводит к тому, что трафик пользователей или проверок работоспособности не может достичь кластера. Определение первопричины этого сбоя оказалось затруднительным; он был смоделирован как блокировка между сетевым путем Front Door и региональным штампом. Front Door немедленно обнаруживает этот сбой и исключает метку из ротации.