Шлюз приложений для компонентов контейнеров

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

Основные компоненты

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

Фронтенды шлюза приложений для контейнеров

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

Ассоциации шлюза приложений для контейнеров

• Ресурс сопоставления "Шлюз приложений для контейнеров" является дочерним ресурсом Azure для родительского ресурса "Шлюз приложений для контейнеров".
• Ассоциация шлюза приложений для контейнерных систем определяет точку подключения в виртуальную сеть. Связь — это 1:1 сопоставление ресурса ассоциации с делегированной подсетью Azure.
• Шлюз приложений для контейнеров предназначен для нескольких сопоставлений.
  • В настоящее время текущее число ассоциаций ограничено 1.
• Во время создания ассоциации базовый уровень данных подготавливается и подключается к подсети в подсети определенной виртуальной сети.
• Каждая ассоциация должна предполагать, что во время подготовки в подсети доступно не менее 256 адресов.
  • Минимальная маска подсети /24 должна быть установлена для каждого развертывания, при условии отсутствия предварительно предоставленных ресурсов в этой подсети.
    • Если вы планируете развернуть несколько ресурсов шлюза приложений для контейнеров, использующих одну подсеть, вычислите необходимые адреса как n×256, где n равно количеству ресурсов шлюза приложений для контейнеров. Предполагается, что каждая из них содержит одну ассоциацию.
  • Все ресурсы связи шлюза приложений для контейнеров должны совпадать с тем же регионом, что и родительский ресурс шлюза приложений для контейнеров.

Группы безопасности сети в подсети ассоциации

Для ассоциаций, созданных начиная с 23 апреля 2026 г., группы безопасности сети (NSG) полностью поддерживаются в подсети шлюза приложений для контейнеров. Это включает как правила для входящего, так и исходящего трафика .

Для ассоциаций, созданных до 23 апреля 2026 г., можно настроить правила входящего NSG; Однако входящий трафик на портах 80 и 443 всегда разрешен независимо от настроенных правил.

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

• Правила "Запретить все входящие" блокируют трафик через порты 80 и 443, если явные правила разрешения не определены, предотвращая доступ к фронтенду.
• Запретить все исходящие правила могут блокировать исходящий трафик из прокси-сервера в кластер AKS, если не настроены необходимые исключения исходящего трафика.

Гейтвей приложений для контейнерных контроллеров ALB

• Шлюз приложений для контейнеров с контроллером ALB — это развертывание Kubernetes, которое выполняет оркестрацию конфигурации и развертывания шлюза приложений для контейнеров, отслеживая как пользовательские ресурсы Kubernetes, так и конфигурации ресурсов, такие как, например, но не ограничиваясь, Ingress, Gateway и ApplicationLoadBalancer. Он использует API конфигурации ARM и Шлюза приложений для контейнеров для распространения конфигурации в шлюз приложений для развертывания Azure.
• Развертывание или установка контроллера ALB с помощью Helm.
• Контроллер ALB состоит из двух запущенных модулей pod.
  • Модуль pod alb-controller управляет намерением клиента в шлюз приложений для конфигурации балансировки нагрузки контейнеров.
  • Объект pod alb-controller-bootstrap управляет CRD.

Политика безопасности шлюза приложений для контейнеров

• Политика безопасности шлюза приложений для контейнеров определяет конфигурации безопасности, такие как WAF, для использования контроллером ALB.
• Один ресурс Шлюза приложений для контейнеров может ссылаться на несколько политик безопасности.
• В настоящее время единственным типом политики безопасности являются waf функции брандмауэра для веб-приложений.
• Политика waf безопасности — это сопоставление между ресурсом политики безопасности и политикой брандмауэра веб-приложения.
  • Можно ссылаться только на одну политику брандмауэра веб-приложения в любом количестве политик безопасности для определенного ресурса Шлюза приложений для контейнеров.

Управляемое дополнение AKS для шлюза приложений для контейнеров

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

Ниже приведены некоторые преимущества использования управляемой надстройки по сравнению с развертыванием на основе helm:

• Управляемые обновления: Не нужно вручную обновлять диаграммы Helm; обновления управляются AKS.
• Автоматическое управление удостоверениями: Надстройка автоматически создает и настраивает управляемое удостоверение (applicationloadbalancer-<cluster-name>) с необходимыми разрешениями.
• Упрощенная конфигурация подсети: Выделенная подсеть (aks-appgateway) автоматически подготавливается с правильным делегированием.
• Уменьшена сложность конфигурации: Не нужно вручную настраивать федеративные учетные данные или назначения ролей.
• Автоматическая поддержка AKS: Развертывание дополнений требуется при использовании кластеров AKS с автоматической настройкой.

Azure / Общие понятия

Частный IP-адрес

• Частный IP-адрес не определяется явным образом как ресурс Azure Resource Manager. Частный IP-адрес ссылается на определенный адрес узла в подсети данной виртуальной сети.

Делегирование подсети

• Microsoft.ServiceNetworking/trafficControllers — это пространство имен, принятое шлюзом приложений для контейнеров, и вы можете делегировать его подсети виртуальной сети.
• Когда вы делегируете, вы не подготавливаете ресурсы Application Gateway для контейнеров, и также нет исключительного сопоставления с ресурсом ассоциации Application Gateway для контейнеров.
• Любое количество подсетей может иметь делегирование подсети, которое одинаково или отличается от шлюза приложений для контейнеров. После определения вы не сможете подготовить другие ресурсы в подсети, если не определено явным образом реализацией службы.

Управляемая идентификация, назначаемая пользователем

• Управляемые удостоверения для ресурсов Azure устраняют потребность в управлении учетными данными в коде.
• Для каждого контроллера балансировки нагрузки Azure необходимо назначить управляемую идентичность, назначаемую пользователем, чтобы внести изменения в шлюз приложений для контейнеров.
• AppGw for Containers Configuration Manager — это встроенная роль RBAC, которая позволяет контроллеру балансировки нагрузки получать доступ к ресурсу контейнеров и настраивать шлюз приложений для контейнеров.

Как шлюз приложений для контейнеров принимает запрос

Каждый фронтенд шлюза приложений для контейнеров предоставляет сгенерированное полное доменное имя, управляемое Azure. Полностью квалифицированное доменное имя можно использовать в неизменном виде или маскировать его с помощью записи CNAME.

Прежде чем клиент отправит запрос к шлюзу приложений для контейнеров, он сначала разрешает CNAME, который указывает на полное доменное имя интерфейса, или напрямую разрешает полное доменное имя, предоставленное шлюзом приложений для контейнеров, используя DNS-сервер.

Сопоставитель DNS преобразует запись DNS в IP-адрес.

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

Набор правил маршрутизации оценивает, как следует отправить запрос с тем же именем узла на определенный целевой объект в серверной части.

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

Запросы HTTP/2

Шлюз приложений для контейнеров поддерживает протоколы HTTP/2 и HTTP/1.1 для взаимодействия между клиентом и интерфейсом. Параметр HTTP/2 всегда включен и не может быть изменен. Если клиенты предпочитают использовать HTTP/1.1 для взаимодействия с интерфейсом шлюза приложений для контейнеров, они могут продолжать вести переговоры соответствующим образом.

Обмен данными между шлюзом приложений для контейнеров и целевой серверной частью всегда осуществляется через HTTP/1.1, за исключением gRPC, который использует HTTP/2.

Изменения в запросе

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

• X-forwarded-for
• x-forwarded-proto
• x-request-id (идентификатор запроса)

X-forwarded-for — это IP-адрес клиента, который сделал исходный запрос. Если запрос поступает через прокси-сервер, к значению заголовка добавляется полученный адрес, разделённый запятой. Например: 1.2.3.4,5.6.7.8; где 1.2.3.4 — это IP-адрес клиента для прокси-сервера перед шлюзом приложений для контейнеров, а 5.6.7.8 — адрес прокси-сервера пересылки трафика в шлюз приложений для контейнеров.

X-forwarded-proto возвращает протокол, который шлюз приложений для контейнеров получает от клиента. Значение может быть либо http, либо https.

X-request-id — это уникальный GUID, который шлюз приложений для контейнеров создает для каждого клиентского запроса и передает в переадресованном запросе на целевую серверную сторону. GUID состоит из 32 буквенно-цифровых символов, разделенных дефисами (например, aaaa0000-bb11-2222-33cc-444444dddddd). Этот guid можно использовать для сопоставления запроса, который шлюз приложений для контейнеров получает и инициирует с серверным целевым объектом, как определено в журналах доступа.

Время ожидания запроса

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

Подключение

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

Исходящее подключение контроллера ALB

Подключение входящих соединений к контроллеру ALB

Подключение фронтенда

Каждый интерфейс для шлюза приложений для контейнеров находится в формате *.fzXX.alb.azure.com, где XX — числовые цифры 0-99. Фронтенды могут прослушивать только через порты 443 и 80.