Share via

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Управляемое удостоверение, назначаемое пользователем

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

Примечание.

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

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

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

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

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

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

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

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

Запросы HTTP/2

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

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

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

  • 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 буквенно-цифровых символов, разделенных дефисом (например, d23387ab-e629-458a-9c93-6108d374bc75). Этот guid можно использовать для сопоставления запроса, полученного Шлюз приложений для контейнеров и инициированного к целевому объекту серверной части, как определено в журналах доступа.

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

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

Время ожидания Длительность Description
Истекло время ожидания запроса 60 секунд время, для которого Шлюз приложений для контейнеров ожидается ответ серверной части.
Время ожидания простоя HTTP 5 мин Время ожидания простоя перед закрытием HTTP-подключения.
Время ожидания простоя потока 5 мин Время ожидания простоя перед закрытием отдельного потока, выполняемого HTTP-подключением.
Время ожидания Подключение вышестоящей Подключение 5 секунд время для установления подключения к целевому объекту серверной части.