Сценарии и ресурсы виртуальной сети для Экземпляры контейнеров Azure

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

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

Сценарии

Группы контейнеров, развернутых в виртуальной сети Azure, позволяют реализовать такие сценарии:

• Прямая связь между группами контейнеров в одной подсети.
• Отправьте выходные данные задачной рабочей нагрузки из экземпляров контейнеров в базу данных, расположенную в виртуальной сети.
• Получение содержимого для экземпляров контейнеров из конечной точки службы в виртуальной сети.
• Включите обмен данными контейнера с локальными ресурсами через VPN-шлюз или ExpressRoute.
• Интегрируйте с брандмауэром Azure , чтобы определить исходящий трафик, исходящий из контейнера.
• Разрешите имена через внутренний DNS Azure для связи с ресурсами Azure в виртуальной сети, такими как виртуальные машины.
• Используйте правила NSG для управления доступом контейнера к подсетям или другим сетевым ресурсам.
• Разверните масштабируемое контейнерное приложение с помощью экземпляров контейнеров Azure (ACI) и равномерно распределяйте входящий трафик между несколькими группами контейнеров с помощью Azure Load Balancer (цен. категория "Стандартный").

Неподдерживаемые сценарии сети

• Пиринг глобальной виртуальной сети — глобальный пиринг (подключение виртуальных сетей между регионами Azure) не поддерживается.
• Общедоступный IP-адрес или метка DNS — группы контейнеров, развернутые в виртуальной сети, в настоящее время не поддерживают доступ к контейнерам непосредственно в Интернете с общедоступным IP-адресом или полным доменным именем.
• Управляемое удостоверение с виртуальной сетью в регионах Azure для государственных организаций - Управляемое удостоверение с возможностями виртуальной сети не поддерживается в регионах Azure для государственных организаций.
• Извлечение изображений из частных реестров, отличных от ACR, — ACI не поддерживает извлечение образов контейнеров из частных реестров (реестров без общедоступного IP-адреса), отличных от Реестр контейнеров Azure (ACR). Даже если между ACI и собственным частным реестром есть подключение к виртуальной сети, извлечение образов из частных реестров, отличных от ACR, не поддерживается. Для закрытого получения образов используйте ACR с частной конечной точкой доступа и управляемым удостоверением личности

Другие ограничения

• Для развертывания группы контейнеров в подсети эта подсеть не должна содержать другие типы ресурсов. Удалите все существующие ресурсы из существующей подсети перед развертыванием групп контейнеров в ней или создайте новую подсеть.
• Чтобы развернуть группы контейнеров в подсети, подсеть и группа контейнеров должны находиться в одной и той же подписке Azure.
• Из-за задействованных дополнительных сетевых ресурсов развертывание в виртуальной сети обычно происходит медленнее, чем развертывание стандартного экземпляра контейнера.
• Используйте подсеть по крайней мере /24 (256 адресов) для развертываний групп контейнеров. Подсети меньше /24, как известно, вызывают сбои развертывания подсети, так как Экземпляры контейнеров Azure не удается освободить сопоставления IP-адресов достаточно быстро для повторного использования.
• Исходящие подключения к порту 25 и 19390 в настоящее время не поддерживаются. Порт 19390 необходимо открыть в брандмауэре для подключения к ACI из портал Azure при развертывании групп контейнеров в виртуальных сетях.
• Для входящих подключений брандмауэр также должен разрешать все IP-адреса в виртуальной сети.
• Если вы подключаете группу контейнеров к учетной записи службы хранения Azure, необходимо добавить конечную точку службы в этот ресурс.
• В настоящее время адреса IPv6 не поддерживаются.
• В зависимости от типа подписки некоторые порты могут быть заблокированы.
• Экземпляры контейнеров не считывают или наследуют параметры DNS из связанной виртуальной сети. Параметры DNS должны быть явно заданы для экземпляров контейнеров.
• Чтобы развернуть группы контейнеров в подсети, убедитесь, что масштабирование выполняется с шагом 1000 групп контейнеров на подсеть и что максимальное количество групп контейнеров на одну подсеть не превышает 3000. В большинстве случаев пересечение этих ограничений приведет к снижению производительности. Поэтому для большинства производственных нагрузок в качестве рекомендуемой отправной точки следует распределять развертывания групп контейнеров по подсетям с соблюдением вышеупомянутых ограничений.

Развертывание групп контейнеров в виртуальной сети

Для развертывания групп контейнеров в виртуальной сети требуется три ресурса виртуальной сети Azure: сама виртуальная сеть, делегированная подсеть в пределах этой виртуальной сети и сетевой профиль.

Виртуальная сеть

Виртуальная сеть определяет адресное пространство, в котором можно создать одну или несколько подсетей. Затем следует развернуть ресурсы Azure (например, группы контейнеров) в подсетях виртуальной сети.

Подсеть (делегированная)

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

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

Исходящее подключение

Шлюз NAT должен быть настроен с общедоступным IP-адресом, чтобы исходящие потоки групп контейнеров проходили через этот общедоступный IP-адрес. Это также позволяет клиентам использовать ip-адреса, помеченные службой, и (или) иметь соответствующие правила NSG.

Используйте следующее руководство "Быстрый старт: Создание шлюза NAT" для создания шлюза NAT.

Сетевые профили

Сетевой профиль — это шаблон конфигурации сети для ресурсов Azure. Он задает определенные свойства сети для ресурса, например подсеть, в который его следует развернуть. При первом использовании команды az container create для развертывания группы контейнеров в подсеть (и, соответственно, в виртуальную сеть) Azure создаст сетевой профиль. Затем этот сетевой профиль можно использовать для будущих развертываний в подсети.

Чтобы использовать шаблон Resource Manager, файл YAML или программный метод для развертывания группы контейнеров в подсеть, необходимо указать полный идентификатор ресурса Resource Manager сетевого профиля. Вы можете использовать профиль, созданный ранее с использованием команды az container create, или создать профиль с помощью шаблона Resource Manager (ознакомьтесь с примером шаблона и справочной документацией). Чтобы получить идентификатор ранее созданного профиля, используйте команду az network profile list.

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

Развертывание групп контейнеров с помощью Azure Load Balancer уровня "Стандартный"

Клиенты могут развертывать масштабируемые контейнерные приложения с помощью экземпляров контейнеров Azure и равномерно распределять входящий трафик между несколькими группами контейнеров с помощью Azure Load Balancer уровня "Стандартный".

Необходимые условия

Клиенты должны создать общедоступную или внутреннюю подсистему балансировки нагрузки с соответствующей конфигурацией ВНЕШНЕГО IP-адреса, пробами работоспособности, правилами балансировки нагрузки и внутренними пулами в соответствии с требованиями рабочей нагрузки.

Пример: Добавление экземпляров ACI в backendpool с помощью Azure CLI

az network lb address-pool update -g MyResourceGroup --lb-name MyLb -n MyAddressPool --vnet MyVnetResource --backend-addresses "[{name:ACI-Instance1,ip-address:10.0.0.5,subnet:subnetName},{name:ACI-Instance2,ip-address:10.0.0.6,subnet:subnetName},{name:ACI-Instance3,ip-address:10.0.0.7,subnet:subnetName}]"

Пример. Добавление экземпляров ACI в серверную часть с помощью PowerShell

$vnetName = "vnetname"
$subnetName = "ACI subnet name"
$resourceGroup = "rg name"
$loadBalancerName = "LB Name"

$virtualNetwork = Get-AzVirtualNetwork -Name $vnetName -ResourceGroupName $resourceGroup
$subnet = Get-AzVirtualNetworkSubnetConfig -Name $subnetName -VirtualNetwork $virtualNetwork
$loadBalancer = Get-AzLoadBalancer -ResourceGroupName $resourceGroup -Name $loadBalancerName
$ip1 = New-AzLoadBalancerBackendAddressConfig -IpAddress "10.0.0.5" -Name "ACI-Instance1" -SubnetId $subnet.Id
$ip2 = New-AzLoadBalancerBackendAddressConfig -IpAddress "10.0.0.6" -Name "ACI-Instance2" -SubnetId $subnet.Id
$ip3 = New-AzLoadBalancerBackendAddressConfig -IpAddress "10.0.0.7" -Name "ACI-Instance3" -SubnetId $subnet.Id
$backendPool = $loadBalancer.BackendAddressPools[0]
$backendPool.LoadBalancerBackendAddresses.Add($ip1)
$backendPool.LoadBalancerBackendAddresses.Add($ip2)
$backendPool.LoadBalancerBackendAddresses.Add($ip3)
Set-AzLoadBalancerBackendAddressPool -InputObject $backendPool

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

• Примеры развертывания с помощью Azure CLI см. в статье Развертывание экземпляров контейнеров в виртуальной сети Azure.
• Сведения о развертывании новой виртуальной сети, подсети, профиля сети и группы контейнеров с помощью шаблона Resource Manager см. в статье "Создание группы контейнеров Azure с виртуальной сетью".
• При использовании портал Azure для создания экземпляра контейнера можно также указать параметры для новой или существующей виртуальной сети на вкладке "Сеть".