Сеть в среде приложений контейнеров Azure
Приложения контейнеров Azure выполняются в контексте среды с собственной виртуальной сетью ( виртуальной сетью).
По умолчанию для вашей среды Контейнера приложения автоматически создается виртуальная сеть. Для точного контроля над сетью при создании среды можно указать существующую виртуальную сеть. После создания среды с новой или существующей виртуальной сетью тип сети уже нельзя изменить.
Созданные виртуальные сети принимают следующие характеристики.
В их число входят:
- Недоступно для вас по мере их создания в клиенте Майкрософт
- общедоступный доступ через Интернет
- доступ к конечным точкам с доступом к Интернету
Кроме того, они поддерживают только ограниченное подмножество сетевых возможностей, таких как ограничения IP-адресов входящего трафика и элементы управления входящего трафика на уровне контейнера.
Используйте существующую виртуальную сеть, если вам нужны дополнительные функции сети Azure, например:
- Интеграция с Шлюз приложений
- группы сетевой безопасности;
- Взаимодействие с ресурсами за частными конечными точками в виртуальной сети
Доступные функции виртуальной сети зависят от выбранной среды.
Выбор среды
Контейнерные приложения имеют два разных типа среды, которые используют многие из одних и те же сетевых характеристик с некоторыми ключевыми различиями.
| Тип среды | Description | Поддерживаемые типы планов |
|---|---|---|
| Профили рабочей нагрузки | Поддерживает определяемые пользователем маршруты (UDR) и исходящие данные через шлюз NAT. Минимальный обязательный размер подсети — /27. |
Потребление, выделенное |
| Только за использование | Не поддерживает определяемые пользователем маршруты (UDR), исходящие данные через шлюз NAT, пиринг через удаленный шлюз или другие пользовательские исходящие данные. Минимальный обязательный размер подсети — /23. |
Потребление |
Уровни специальных возможностей
Вы можете настроить, разрешает ли приложение-контейнер общедоступный вход или входящий трафик только из виртуальной сети на уровне среды.
| Уровень специальных возможностей | Description |
|---|---|
| Внешний | Позволяет приложению-контейнеру принимать общедоступные запросы. Внешние среды развертываются с виртуальным IP-адресом на внешнем, общедоступном IP-адресе. |
| Внутренний | Внутренние среды не имеют общедоступных конечных точек и развертываются с виртуальным IP-адресом, сопоставленным с внутренним IP-адресом. Внутренняя конечная точка — это внутренняя подсистема балансировки нагрузки Azure (ILB), а IP-адреса выдаются из списка частных IP-адресов настраиваемой виртуальной сети. |
Настраиваемая конфигурация виртуальной сети
При создании пользовательской виртуальной сети следует учитывать следующие ситуации:
Если вы хотите, чтобы приложение-контейнер ограничивалось всем внешним доступом , создайте внутреннюю среду приложений контейнеров.
Если вы используете собственную виртуальную сеть, необходимо предоставить подсеть, выделенную исключительно для развернутой среды приложения-контейнера. Эта подсеть недоступна другим службам.
Сетевые адреса назначаются из диапазона подсети, определяемого как среда создается.
Можно определить диапазон подсети, используемый средой "Приложения контейнеров".
Вы можете ограничить входящие запросы в среду исключительно виртуальной сетью, развернув среду как внутреннюю.
Примечание.
При предоставлении собственной виртуальной сети создаются дополнительные управляемые ресурсы . Эти ресурсы повысят затраты на связанные с ними ставки.
При начале разработки сети вокруг приложения-контейнера обратитесь к разделу "Планирование виртуальных сетей".
Примечание.
Перемещение виртуальных сетей между различными группами ресурсов или подписками запрещено, если виртуальная сеть используется средой "Приложения контейнеров".
Поведение прокси-сервера 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 выполняется вне области среды приложений-контейнеров.
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 CLI".
Интеграция приложений-контейнеров с Шлюз приложений.
Настройте UDR для маршрутизации всего трафика через Брандмауэр Azure.
Шифрование сети уровня среды (предварительная версия)
Приложения контейнеров Azure поддерживают шифрование сети уровня среды с помощью взаимной безопасности уровня транспорта (mTLS). Если требуется сквозное шифрование, mTLS шифрует данные, передаваемые между приложениями в среде.
Приложения в среде контейнерных приложений автоматически проходят проверку подлинности. Однако среда выполнения контейнерных приложений не поддерживает авторизацию для управления доступом между приложениями с помощью встроенного mTLS.
Когда приложения взаимодействуют с клиентом за пределами среды, поддерживается двусторонняя проверка подлинности с помощью MTLS. Дополнительные сведения см. в статье о настройке сертификатов клиента.
Примечание.
Включение mTLS для приложений может увеличить задержку отклика и уменьшить максимальную пропускную способность в сценариях высокой нагрузки.
Вы можете включить MTLS с помощью следующих команд.
При создании:
az containerapp env create \
--name <environment-name> \
--resource-group <resource-group> \
--location <location> \
--enable-mtls
Для существующего приложения-контейнера:
az containerapp env update \
--name <environment-name> \
--resource-group <resource-group> \
--enable-mtls
DNS
Пользовательский DNS: если виртуальная сеть использует пользовательский DNS-сервер вместо DNS-сервера, предоставленного По умолчанию, настройте DNS-сервер для перенаправления неразрешенных ЗАПРОСОВ DNS в
168.63.129.16. Рекурсивные сопоставители Azure используют этот IP-адрес для разрешения запросов. При настройке группы безопасности сети или брандмауэра не блокируйте168.63.129.16адрес, в противном случае среда приложений контейнеров не будет работать правильно.Входящий трафик виртуальной сети область. Если вы планируете использовать входящий трафик виртуальной сети область во внутренней среде, настройте домены одним из следующих способов:
Не настраиваемые домены. Если вы не планируете использовать личный домен, создайте частную зону DNS, которая разрешает домен по умолчанию среды "Приложения контейнеров" статическим IP-адресом среды "Приложения контейнеров". Вы можете использовать Azure Частная зона DNS или собственный DNS-сервер. Если вы используете Azure Частная зона DNS, создайте частную зону DNS с именем домена по умолчанию среды приложения-контейнера (
<UNIQUE_IDENTIFIER>.<REGION_NAME>.azurecontainerapps.io) с записьюA. ЗаписьAсодержит имя*<DNS Suffix>и статический IP-адрес среды приложений контейнеров.Личные домены. Если вы планируете использовать личные домены и используете внешнюю среду контейнерных приложений, используйте общедоступный разрешенный домен для добавления личного домена и сертификата в приложение контейнера. Если вы используете внутреннюю среду Контейнера приложений, проверка привязки 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 выставляются счета:
Один стандартный статический общедоступный IP-адрес для исходящего трафика при использовании внутренней или внешней среды, а также один стандартный статический общедоступный IP-адрес для входящего трафика при использовании внешней среды. Если вам нужны более общедоступные IP-адреса для исходящего трафика из-за проблем SNAT, откройте запрос в службу поддержки, чтобы запросить переопределение.
Одна стандартная подсистема балансировки нагрузки.
Стоимость обработанных данных (в GBS) включает как входящий трафик, так и исходящий трафик для операций управления.
Только среда потребления
Имя группы ресурсов, созданной в подписке Azure, в которой размещена среда, по умолчанию имеет префикс MC_ , и имя группы ресурсов невозможно настроить при создании приложения контейнера. Группа ресурсов содержит общедоступные IP-адреса, используемые специально для исходящего подключения из вашей среды и подсистемы балансировки нагрузки.
В дополнение к стандартному выставлению счетов за приложения контейнеров Azure выставляются счета:
Один стандартный статический общедоступный IP-адрес для исходящего трафика. Если вам требуется больше IP-адресов для исходящего трафика из-за проблем с преобразованием исходных сетевых адресов (SNAT), откройте запрос в службу поддержки, чтобы запросить переопределение.
Два стандартных подсистемы балансировки нагрузки , если используется внутренняя среда или одна стандартная подсистема балансировки нагрузки при использовании внешней среды. Каждый балансировщик нагрузки имеет менее шести правил. Стоимость обработанных данных (в GBS) включает как входящий трафик, так и исходящий трафик для операций управления.