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

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

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

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

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

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

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

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

Гейтвей приложений для контейнерных контроллеров 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 безопасности — это сопоставление между ресурсом политики безопасности и политикой брандмауэра веб-приложения.
  • Только одна политика брандмауэра веб-приложения может быть указана в любом числе политик безопасности для заданного ресурса Шлюз приложений для контейнеров.

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

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

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

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

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

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

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

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

Каждый интерфейс шлюза приложений для контейнеров предоставляет созданное полное доменное имя, управляемое Azure. Полное доменное имя (ПДИ) может использоваться as-is, или клиенты могут маскировать ПДИ при помощи записи 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). Этот идентификатор можно использовать для определения соответствия запроса, полученного шлюзом приложений для контейнеров, и инициирования его на серверный целевой объект, как это указано в журналах доступа.

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

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