Надежность в шлюзе приложений Azure для контейнеров

Шлюз приложений Azure для контейнеров — это управляемая служба балансировки нагрузки на уровне приложений (уровень 7) и динамического управления трафиком для рабочих нагрузок, работающих в Kubernetes. Он направляет входящие запросы к целевым серверам в вашем кластере.

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

В этой статье описывается, как Шлюз приложений Azure for Containers обрабатывает временные ошибки, сбои зоны доступности, сбои в пределах региона и обслуживание служб. В нем также описываются параметры резервного копирования и восстановления, а также ключевые сведения о соглашении об уровне обслуживания (SLA).

Обзор архитектуры надежности

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

Логическая архитектура

Развертывание Application Gateway for Containers включает ресурсы в Azure и в кластере Kubernetes.

Azure ресурсы:плоскость управления управляет конфигурацией прокси-сервера шлюза на основе вашей конфигурации. Плоскость данных, управляемая Azure, выполняется за пределами кластера и обрабатывает трафик приложения.
Ресурсы Kubernetes: Вы определяете маршрутизацию и другую конфигурацию с помощью ресурсов Kubernetes. Контроллер ALB выполняется в кластере, просматривает эти ресурсы и передает вашу конфигурацию в Application Gateway for Containers в Azure.

Вы можете выбрать одну из двух стратегий развертывания. С помощью стратегии bring your own (BYO) вы управляете жизненным циклом шлюза приложений для контейнеров, ассоциаций и интерфейсных ресурсов с помощью средств Azure. При использовании стратегии «управляется контроллером ALB» контроллер ALB управляет жизненным циклом этих ресурсов Azure на основе определяемых вами ресурсов Kubernetes.

Полное описание компонентов см. в разделе компоненты Application Gateway for Containers.

После развертывания и настройки Application Gateway for Containers он направляет входящие запросы к внутренним целевым объектам, которые представляют приложение, работающее в Kubernetes.

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

Физическая архитектура

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

Устойчивость к временным сбоям

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

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

При использовании шлюза приложений для контейнеров рассмотрите следующие рекомендации.

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

Устойчивость к сбоям зоны доступности

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

При развертывании Application Gateway for Containers в регионе Azure, поддерживающем зоны доступности, Microsoft автоматически настраивает плоскость управления и плоскость данных как зонально-избыточные в нескольких зонах. Вы не выбираете, какие зоны использует служба.

Important

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

Требования

Поддержка региона: Чтобы использовать избыточность зон, выберите регион, который поддерживает и Application Gateway for Containers, и зоны доступности. Проверьте доступность Application Gateway for Containers в регионах и сравните её со списком регионов, поддерживающих зоны доступности.

Considerations

Общая ответственность с платформой Kubernetes: Microsoft управляет перенаправлением трафика для Application Gateway for Containers во время сбоя зоны. Для Azure Kubernetes Service (AKS) Microsoft управляет плоскостью управления Kubernetes. Вы несете ответственность за настройку зональной отказоустойчивости для пулов узлов кластера и других ресурсов, которыми вы управляете, а также за поведение приложений во время сбоя зоны.

Кластер: Настройте пулы узлов AKS и другие управляемые вами ресурсы кластера с привязкой к зонам, чтобы они охватывали зоны доступности. AKS управляет плоскостью управления; см. раздел "Настройка зон доступности для пулов узлов AKS".
Ваши рабочие нагрузки: Вы несете ответственность за развертывание нескольких реплик pod, распределение их по зонам и обеспечение работоспособных серверных рабочих нагрузок для обслуживания трафика во время сбоя зоны. Вы можете использовать пулы узлов, охватывающие зоны доступности, ограничения распространения топологии и антиаффинность pod.
Объекты конфигурации Kubernetes: Application Gateway for Containers использует объекты конфигурации Kubernetes, хранящиеся в API кластера. Их доступность зависит от плоскости управления Kubernetes и конфигурации, которой вы управляете в своем кластере.
Контроллер ALB: Вы развертываете контроллер ALB в кластере Kubernetes для приведения конфигурации к целевому состоянию. Он не входит в путь передачи данных Application Gateway for Containers.

Контроллер ALB запускает две реплики, одна из которых выступает в качестве лидера, а другая — в качестве дополнительной. Если лидер становится недоступным, вторичный может стать лидером и продолжить распространение конфигурации. Обе реплики могут выполняться в одной зоне доступности в зависимости от того, как кластер размещает их. Вы отвечаете за настройку модулей pod кластера и модулей pod контроллера для обеспечения зональной отказоустойчивости. Используйте ограничения распространения топологии pod или анти-аффинности pod для распределения реплик между зонами. Дополнительные сведения см. в разделе "Настройка зон доступности для пулов узлов AKS".

Cost

Поддержка зон доступности для Application Gateway for Containers не влечет дополнительных расходов сверх стандартной стоимости службы. Сведения о ценах см. на странице Шлюз приложений Azure pricing.

Настройка поддержки зоны доступности

При развертывании нового шлюза в поддерживаемом регионе он по умолчанию является зонально-избыточным. Вам не нужно включать избыточность зоны для ресурсов Azure.

Вы отвечаете за настройку кластера Kubernetes, ALB Controller и серверных рабочих нагрузок для обеспечения отказоустойчивости на уровне зон.

Поведение, когда все зоны работоспособны

В этом разделе описывается, чего следует ожидать при развертывании Application Gateway for Containers в регионе, поддерживающем зоны доступности, и все зоны, используемые службой, работоспособны.

Межзональная работа: Плоскость данных Application Gateway for Containers, управляемого Azure, распределяет входящие запросы по инфраструктуре в нескольких зонах.

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

Поведение во время сбоя зоны

В этом разделе описывается, что следует ожидать при развертывании Application Gateway for Containers в регионе, поддерживающем зоны доступности, если в одной из зон, используемых службой, произошел сбой.

Обнаружение и ответ: Application Gateway for Containers перенаправляет трафик в инфраструктуру в оставшихся работоспособных зонах во время сбоя зоны. Вам не нужно принимать меры для перераспределения трафика шлюза.

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

Уведомление: Microsoft не уведомляет вас автоматически, когда зона отключена. Однако вы можете использовать Работоспособность служб Azure для понимания общего состояния службы, включая любые сбои зоны, и настроить оповещения Service Health для уведомления о проблемах.

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

Управляемый Azure уровень управления остается доступным во время сбоя в одной зоне. Однако возможность применять обновления конфигурации также зависит от доступности уровня управления Kubernetes и контроллера ALB.
Перераспределение: Шлюз приложений для контейнеров перенаправляет трафик в инфраструктуру в оставшихся здоровых зонах.

Восстановление зоны

Application Gateway for Containers самостоятельно восстанавливается после проблем базовой инфраструктуры. Azure управляет восстановлением инфраструктуры шлюза.

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

Платформа Application Gateway for Containers управляет маршрутизацией трафика и реагированием на сбои зоны для самого шлюза. Вам не нужно инициировать или управлять ответом шлюза. Если у вас есть кластер Kubernetes, которым вы управляете, можно использовать Azure Chaos Studio для тестирования ответа кластера на сбои зоны. Дополнительные сведения см. в разделе "Проверка устойчивости зоны доступности".

Устойчивость к сбоям на уровне региона

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

Кастомные многорегиональные решения для повышения отказоустойчивости

Application Gateway for Containers не предоставляет встроенное многорегионное развертывание или решение для аварийного переключения. Чтобы обеспечить устойчивость к сбою региона, разверните и настройте отдельный шлюз и кластер Kubernetes в каждом регионе. Вы несете ответственность за перенаправление трафика между региональными шлюзами и настройку аварийного переключения.

Последовательно настройте Application Gateway for Containers в разных регионах. Чтобы упростить развертывание и обеспечить соответствие конфигураций, определите инфраструктуру как код (IaC) с помощью таких средств, как Bicep или Terraform.
Выберите и настройте глобальную службу управления трафиком, например Azure Front Door или Диспетчер трафика Azure, для направления клиентов к региональным шлюзам. Эти службы используют различные модели маршрутизации и конфигурации проб работоспособности. Настройте выбранную службу для перенаправления трафика в обход недоступного шлюза и ознакомьтесь с документацией этой службы, чтобы понять поведение маршрутизации и рекомендации по отработке отказа. Azure Front Door также предоставляет такие возможности, как защита от распределенных атак типа «отказ в обслуживании» (DDoS), возможности брандмауэра веб-приложений (WAF) и маршрутизация на основе правил.
Разверните серверные приложения в каждом регионе и настройте их так, чтобы они обеспечивали работоспособность рабочих нагрузок во время сбоя. Если ваши приложения зависят от данных или других служб Azure, проектируйте и настраивайте эти службы также для многорегионной доступности. Ознакомьтесь с рекомендациями по надежности для каждой службы, чтобы понять ее варианты многорегионирования и ограничения.

Резервное копирование и восстановление

Шлюз приложений для контейнеров не хранит данные приложения. Azure Resource Manager сохраняет конфигурацию Azure ресурса шлюза. Эти ресурсы можно повторно создать, повторно развернув их конфигурацию.

Вы несете ответственность за сохранение конфигурации и ресурсов Kubernetes, определяющих развертывание шлюза и маршрутизацию трафика:

Определите ресурсы Azure и их параметры в виде кода инфраструктуры (IaC), например с помощью Bicep или Terraform, и сохраняйте определения в системе контроля версий. Их можно использовать для повторного развертывания ресурсов шлюза.
Создайте резервную копию ресурсов Kubernetes, которые настраивают шлюз, например ApplicationLoadBalancer, Gatewayи HTTPRoute ресурсы. Восстановите их в ваш кластер, когда необходимо повторно создать конфигурацию маршрутизации.
Сохраните связанную конфигурацию, включая пользовательские правила и политики брандмауэра веб-приложения, в управлении версиями или через стандартный процесс резервного копирования конфигурации. Конвейеры развертывания можно использовать для последовательного повторного создания ресурсов Azure и Kubernetes.

Устойчивость к обслуживанию служб

Microsoft управляет обслуживанием Application Gateway for Containers, сохраняя высокий уровень доступности службы.

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

Дополнительные сведения см. в разделе Масштабирование и доступность Application Gateway for Containers.

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Дополнительные сведения см. в разделе SLA для онлайн-услуг.

SLA для Application Gateway for Containers измеряет плоскость управления и плоскость данных отдельно. Оба уровня учитываются в общем расчете SLA.

Обратная связь

Были ли сведения на этой странице полезными?

Последнее обновление: 2026-10-16