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

Сеть в среде приложений контейнеров Azure

  • Статья

Приложения контейнеров Azure выполняются в контексте среды с собственной виртуальной сетью ( виртуальной сетью).

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

Созданные виртуальные сети принимают следующие характеристики.

В их число входят:

  • Недоступно для вас по мере их создания в клиенте Майкрософт
  • общедоступный доступ через Интернет
  • доступ к конечным точкам с доступом к Интернету

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

Используйте существующую виртуальную сеть, если вам нужны дополнительные функции сети Azure, например:

  • Интеграция с Шлюз приложений
  • группы сетевой безопасности;
  • Взаимодействие с ресурсами за частными конечными точками в виртуальной сети

Доступные функции виртуальной сети зависят от выбранной среды.

Выбор среды

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

Тип среды Description Поддерживаемые типы планов
Профили рабочей нагрузки Поддерживает определяемые пользователем маршруты (UDR) и исходящие данные через шлюз NAT. Минимальный обязательный размер подсети — /27. Потребление, выделенное
Только за использование Не поддерживает определяемые пользователем маршруты (UDR), исходящие данные через шлюз NAT, пиринг через удаленный шлюз или другие пользовательские исходящие данные. Минимальный обязательный размер подсети — /23. Потребление

Уровни специальных возможностей

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

Уровень специальных возможностей Description
Внешний Позволяет приложению-контейнеру принимать общедоступные запросы. Внешние среды развертываются с виртуальным IP-адресом на внешнем, общедоступном IP-адресе.
Внутренний Внутренние среды не имеют общедоступных конечных точек и развертываются с виртуальным IP-адресом, сопоставленным с внутренним IP-адресом. Внутренняя конечная точка — это внутренняя подсистема балансировки нагрузки Azure (ILB), а IP-адреса выдаются из списка частных IP-адресов настраиваемой виртуальной сети.

Настраиваемая конфигурация виртуальной сети

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

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

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

  • Сетевые адреса назначаются из диапазона подсети, определяемого как среда создается.

    • Можно определить диапазон подсети, используемый средой "Приложения контейнеров".

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

Примечание.

При предоставлении собственной виртуальной сети создаются дополнительные управляемые ресурсы . Эти ресурсы повысят затраты на связанные с ними ставки.

При начале разработки сети вокруг приложения-контейнера обратитесь к разделу "Планирование виртуальных сетей".

Схема того, как среды контейнеров Azure используют существующую виртуальную сеть или вы можете предоставить собственные.

Примечание.

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

Поведение прокси-сервера http edge

Приложения контейнеров Azure используют прокси-сервер Envoy в качестве пограничного HTTP-прокси. Транспортная безопасность (TLS) завершается на границе, и запросы направляются на основе правил разделения трафика и маршрутизации трафика в правильное приложение.

Приложения HTTP масштабируются на основе количества HTTP-запросов и подключений. Envoy направляет внутренний трафик внутри кластеров.

Подчиненные подключения поддерживают протокол HTTP1.1 и HTTP2 и Envoy автоматически обнаруживает и обновляет подключения, если клиентское подключение требует обновления.

Исходящие подключения определяются путем задания transport свойства объекта ingress .

Конфигурация входящего трафика

В разделе ingress можно настроить следующие параметры:

  • Уровень специальных возможностей. Вы можете настроить приложение-контейнер как внешнее или внутренне доступное в среде. Переменная CONTAINER_APP_ENV_DNS_SUFFIX среды используется для автоматического разрешения полного доменного имени (FQDN) для вашей среды. При взаимодействии между приложениями-контейнерами в одной среде можно также использовать имя приложения. Дополнительные сведения о доступе к приложениям см. в разделе "Входящий трафик" в приложениях контейнеров Azure.

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

Дополнительные сведения о различных сетевых сценариях см. в разделе "Входящий трафик" в приложениях контейнеров Azure.

Зависимости портала

Для каждого приложения в приложениях контейнеров Azure существует два URL-адреса.

Среда выполнения контейнерных приложений изначально создает полное доменное имя (FQDN), используемое для доступа к приложению. См. URL-адрес приложения в окне обзора приложения-контейнера в портал Azure полное доменное имя приложения контейнера.

Для вас также создается второй URL-адрес. Это расположение предоставляет доступ к службе потоковой передачи журналов и консоли. При необходимости может потребоваться добавить https://azurecontainerapps.dev/ список разрешений брандмауэра или прокси-сервера.

Порты и IP-адреса

Следующие порты предоставляются для входящих подключений.

Протокол Порты
HTTP/HTTPS 80, 443

IP-адреса разбиваются на следующие типы:

Тип Описание
Общедоступный входящий IP-адрес Используется для трафика приложений во внешнем развертывании и трафика управления как во внутренних, так и во внешних развертываниях.
Исходящий общедоступный IP-адрес Используется в качестве IP-адреса from для исходящих подключений, которые покидают виртуальную сеть. Эти подключения не маршрутизируются через VPN. Исходящие IP-адреса могут меняться со временем. Использование шлюза NAT или другого прокси-сервера для исходящего трафика из среды приложений контейнеров поддерживается только в среде профилей рабочих нагрузок.
IP-адрес внутренней подсистемы балансировки нагрузки Этот адрес существует только во внутренней среде.

Подсеть

Интеграция виртуальной сети зависит от выделенной подсети. Как IP-адреса выделяются в подсети и какие размеры подсети поддерживаются, зависят от плана , который вы используете в приложениях контейнеров Azure.

Тщательно выберите размер подсети. Размеры подсети нельзя изменить после создания среды "Приложения контейнеров".

Разные типы среды имеют разные требования к подсети:

  • /27 — минимальный размер подсети, необходимый для интеграции виртуальной сети.

  • Подсеть должна быть делегирована Microsoft.App/environments.

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

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

    • Профиль выделенной рабочей нагрузки: по мере масштабирования приложения-контейнера каждый узел имеет один IP-адрес.

    • Профиль рабочей нагрузки потребления: каждый IP-адрес может быть общим для нескольких реплик. При планировании количества IP-адресов, необходимых для приложения, запланируйте 1 IP-адрес на 10 реплик.

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

    Размер подсети Доступные IP-адреса1 Максимальное число узлов (профиль выделенной рабочей нагрузки)2 Максимальное число реплик (профиль рабочей нагрузки потребления)2
    /23 500 250 2500
    /24 244 122 1,220
    /25 116 58 580
    /26 52 26 260
    /27 20 10 100

    1 Доступные IP-адреса — это размер подсети минус 12 IP-адресов, необходимых для инфраструктуры приложений контейнеров Azure.
    2 . Это относится к приложениям в режиме единой редакции.

Ограничения диапазона адресов подсети

Диапазоны адресов подсети не могут перекрываться со следующими диапазонами, зарезервированными Служба Azure Kubernetes:

  • 169.254.0.0/16
  • 172.30.0.0/16
  • 172.31.0.0/16
  • 192.0.2.0/24

Кроме того, среда профилей рабочей нагрузки резервирует следующие адреса:

  • 100.100.0.0/17
  • 100.100.128.0/19
  • 100.100.160.0/19
  • 100.100.192.0/19

Конфигурация подсети с помощью ИНТЕРФЕЙСА командной строки

При создании среды "Приложения контейнеров" вы предоставляете идентификаторы ресурсов для одной подсети.

Если вы используете ИНТЕРФЕЙС командной строки, параметр для определения идентификатора infrastructure-subnet-resource-idресурса подсети. Подсеть размещает компоненты инфраструктуры и контейнеры пользовательских приложений.

Если вы используете Azure CLI только с средой потребления и определен диапазон platformReservedCidr , подсеть не должна перекрываться с диапазоном IP-адресов, определенным в platformReservedCidr.

Маршруты

Определяемые пользователем маршруты (UDR)

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

Примечание.

При использовании UDR с Брандмауэр Azure в приложениях контейнеров Azure необходимо добавить определенные теги полного доменного имени и службы в список разрешений брандмауэра. Дополнительные сведения см. в статье о настройке UDR с помощью Брандмауэр Azure.

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

  • Настройка UDR выполняется вне области среды приложений-контейнеров.

Схема реализации UDR для контейнерных приложений.

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

Настройка UDR с помощью Брандмауэр Azure

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

Примечание.

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

Правила приложений

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

Сценарии Полные доменные имена Description
Все сценарии mcr.microsoft.com, *.data.mcr.microsoft.com Эти полные доменные имена для реестра контейнеров Майкрософт (MCR) используются приложениями контейнеров Azure, и эти правила приложений или сетевые правила для MCR должны быть добавлены в список разрешений при использовании приложений контейнеров Azure с Брандмауэр Azure.
Реестр контейнеров Azure (ACR) Ваш адрес ACR, *.blob.core.windows.net, login.microsoft.com Эти полные доменные имена требуются при использовании приложений контейнеров Azure с ACR и Брандмауэр Azure.
Azure Key Vault Адрес Azure-Key-Vault, login.microsoft.com Эти полные доменные имена требуются в дополнение к тегу службы, необходимому для сетевого правила для Azure Key Vault.
Управляемое удостоверение *.identity.azure.net, , login.microsoftonline.com*.login.microsoftonline.com*.login.microsoft.com Эти полные доменные имена требуются при использовании управляемого удостоверения с Брандмауэр Azure в приложениях контейнеров Azure.
Реестр Docker Hub hub.docker.com, , registry-1.docker.ioproduction.cloudflare.docker.com Если вы используете реестр Docker Hub и хотите получить доступ к нему через брандмауэр, необходимо добавить эти полные доменные имена в брандмауэр.
Правила сети

Правила сети разрешают или запрещают трафик на основе сетевого и транспортного уровня. В зависимости от сценария требуются следующие правила сети брандмауэра исходящего трафика.

Сценарии Тег службы Description
Все сценарии MicrosoftContainerRegistry, AzureFrontDoorFirstParty Эти теги службы для реестра контейнеров Майкрософт (MCR) используются приложениями контейнеров Azure, и эти сетевые правила или правила приложения для MCR должны быть добавлены в список разрешений при использовании приложений контейнеров Azure с Брандмауэр Azure.
Реестр контейнеров Azure (ACR) AzureContainerRegistry, AzureActiveDirectory При использовании ACR с приложениями контейнеров Azure необходимо настроить эти правила приложения, используемые Реестр контейнеров Azure.
Azure Key Vault AzureKeyVault, AzureActiveDirectory Эти теги службы необходимы в дополнение к полному доменному имени для правила приложения для Azure Key Vault.
Управляемое удостоверение AzureActiveDirectory При использовании управляемого удостоверения с приложениями контейнеров Azure необходимо настроить эти правила приложения, используемые управляемым удостоверением.

Примечание.

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

Интеграция шлюза NAT

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

При настройке шлюза NAT в подсети шлюз NAT предоставляет статический общедоступный IP-адрес для вашей среды. Весь исходящий трафик из приложения контейнера направляется через статический общедоступный IP-адрес шлюза NAT.

Безопасность среды

Схема того, как полностью заблокировать сеть для контейнерных приложений.

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

Одноранговая шифрование в среде "Приложения контейнеров Azure"

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

Примечание.

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

В следующем примере показана среда с включенным одноранговым шифрованием. Схема шифрования и расшифровки трафика с включенным одноранговым шифрованием.

1 Входящий трафик TLS завершается на прокси-сервере входящего трафика на границе среды.

2 трафика из прокси-сервера входящего трафика в среде шифруются с помощью закрытого сертификата и расшифровываются получателем.

3 Вызовы, сделанные из приложения A в полное доменное имя приложения B, сначала отправляются на пограничный прокси-сервер входящего трафика и шифруются TLS.

4 Вызова, сделанные из приложения A в приложение B с использованием имени приложения B, отправляются непосредственно в приложение B и шифруются TLS.

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

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

Вы можете включить одноранговую шифрование с помощью следующих команд.

При создании:

az containerapp env create \
    --name <environment-name> \
    --resource-group <resource-group> \
    --location <location> \
    --enable-peer-to-peer-encryption

Для существующего приложения-контейнера:

az containerapp env update \
    --name <environment-name> \
    --resource-group <resource-group> \
    --enable-peer-to-peer-encryption

DNS

  • Пользовательский DNS: если виртуальная сеть использует пользовательский DNS-сервер вместо DNS-сервера, предоставленного По умолчанию, настройте DNS-сервер для перенаправления неразрешенных ЗАПРОСОВ DNS в 168.63.129.16. Рекурсивные сопоставители Azure используют этот IP-адрес для разрешения запросов. При настройке группы безопасности сети или брандмауэра не блокируйте 168.63.129.16 адрес, в противном случае среда приложений контейнеров не будет работать правильно.

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

    1. Не настраиваемые домены. Если вы не планируете использовать личный домен, создайте частную зону DNS, которая разрешает домен по умолчанию среды "Приложения контейнеров" статическим IP-адресом среды "Приложения контейнеров". Вы можете использовать Azure Частная зона DNS или собственный DNS-сервер. Если вы используете Azure Частная зона DNS, создайте частную зону DNS с именем домена по умолчанию среды приложения-контейнера (<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io) с записьюA. Запись A содержит имя *<DNS Suffix> и статический IP-адрес среды приложений контейнеров.

    2. Личные домены. Если вы планируете использовать личные домены и используете внешнюю среду контейнерных приложений, используйте общедоступный разрешенный домен для добавления личного домена и сертификата в приложение контейнера. Если вы используете внутреннюю среду Контейнера приложений, проверка привязки DNS не проводится, так как доступ к кластеру можно получить только из виртуальной сети. Кроме того, создайте частную зону DNS, которая разрешает домен вершины в виде статического IP-адреса среды Контейнеров приложений. Вы можете использовать Azure Частная зона DNS или собственный DNS-сервер. Если вы используете Azure Частная зона DNS, создайте зону Частная зона DNS с именем в качестве домена вершины с записью, A указывающей на статический IP-адрес среды "Приложения контейнеров".

Статический IP-адрес среды "Приложения контейнеров" доступен в портал Azure в пользовательском DNS-суффиксе страницы приложения контейнера или с помощью команды Azure CLIaz containerapp env list.

Управляемые ресурсы

При развертывании внутренней или внешней среды в собственной сети создается новая группа ресурсов в подписке Azure, в которой размещена ваша среда. Эта группа ресурсов содержит компоненты инфраструктуры, управляемые платформой "Контейнеры приложений Azure". Не изменяйте службы в этой группе или самой группе ресурсов.

Среда профилей рабочей нагрузки

Имя группы ресурсов, созданной в подписке Azure, в которой размещена среда, имеет префикс ME_ по умолчанию, а имя группы ресурсов можно настроить при создании среды приложения контейнера.

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

В дополнение к стандартному выставлению счетов за приложения контейнеров Azure выставляются счета:

Только среда потребления

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

В дополнение к стандартному выставлению счетов за приложения контейнеров Azure выставляются счета:

Следующие шаги