Настройка сети Azure CNI в Службе Azure Kubernetes (AKS)

Статья
07/19/2022
Чтение занимает 16 мин

По умолчанию кластеры AKS используют kubenet, а также создается виртуальная сеть и подсеть. При использовании kubenet узлы получают IP-адрес из подсети виртуальной сети. Затем настраивается преобразование сетевых адресов (NAT) на узлах, а модули получают IP-адрес, "скрытый" за IP-адресом узла. Такой подход уменьшает количество IP-адресов, которые необходимо зарезервировать в пространстве сети для модулей pod.

С помощью сетевого интерфейса контейнеров Azure (CNI) каждый объект pod получает IP-адрес из подсети, и к этому объекту pod можно получить прямой доступ. Эти IP-адреса должны быть уникальными во всей сети, и их следует планировать заранее. Для каждого узла предусмотрен параметр конфигурации, в котором указывается максимальное число объектов pod, которые он поддерживает. Затем на каждом узле заранее резервируется эквивалентное число IP-адресов для этого узла. Этот подход требует дополнительного планирования и часто приводит к исчерпанию IP-адресов или необходимости повторно создавать кластеры в подсети большего размера по мере увеличения потребностей вашего приложения.

В этой статье показано, как использовать сеть Azure CNI, чтобы создавать и использовать подсеть виртуальной сети для кластера AKS. Дополнительные сведения о сетях см. в статье Основные понятия сети в Службе Azure Kubernetes (AKS).

Предварительные требования

Виртуальная сеть для кластера AKS должна разрешать исходящее подключение к Интернету.
Кластеры AKS могут не использовать 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 или 192.0.2.0/24 в качестве диапазона адресов службы Kubernetes, диапазона адресов pod или диапазона адресов виртуальной сети кластера.
Удостоверение кластера, используемое кластером AKS, должно иметь по крайней мере разрешения Участник сетей в подсети виртуальной сети. Если вы хотите определить пользовательскую роль вместо того, чтобы использовать встроенную роль участника сети, требуются следующие разрешения:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
Подсеть, назначенная пулу узлов AKS, не может быть делегированной.
AKS не применяет группы безопасности сети (NSG) к своей подсети и не будет изменять ни одну из групп безопасности сети, связанных с этой подсетью. Если вы предоставляете свою собственную подсеть и добавляете группы безопасности сети, связанные с этой подсетью, необходимо убедиться, что правила безопасности в группах безопасности сети разрешают трафик в пределах диапазона CIDR узла. Дополнительные сведения см. в разделе Группы безопасности сети.

Планирование назначения IP-адресов для кластера

Для кластеров, настроенных с помощью сети Azure CNI, требуется дополнительное планирование. Размер виртуальной сети и подсети должен быть достаточным для количества контейнеров pod, которые будут одновременно запускаться, а также соответствовать количеству узлов в кластере.

IP-адреса для контейнеров pod и узлов кластера назначаются из определенной подсети в виртуальной сети. Каждый узел настраивается с помощью основного IP-адреса. По умолчанию 30 дополнительных IP-адресов предварительно настроены с помощью CNI Azure, которые назначаются для модулей, которые запланированы на узле. При масштабировании кластера каждый узел настраивается аналогичным образом с использованием IP-адресов из подсети. Вы также можете просмотреть Максимальное число контейнеров pod на узле.

Важно!

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

При обновлении кластера AKS в нем развертывается новый узел. Службы и рабочие нагрузки теперь выполняются на новом узле, а старый узел удаляется из кластера. Для выполнения этого процесса последовательного обновления требуется, чтобы был доступен как минимум один дополнительный блок IP-адресов. Количество узлов будет равно n + 1.
- Это особенно важно при использовании пулов узлов Windows Server. Узлы Windows Server в AKS не применяют обновления Windows автоматически, вместо этого вам следует выполнять обновление пула узлов. Во время этого обновления развертываются новые узлы на основе последнего образа базового узла Windows Server 2019 с исправлениями безопасности. Дополнительные сведения об обновлении пула узлов Windows Server см. в статье Обновление пула узлов.
При масштабировании кластера AKS в него развертывается новый узел. Службы и рабочие нагрузки теперь выполняются на новом узле. При выборе диапазона IP-адресов следует учитывать, как может понадобиться увеличить количество узлов и контейнеров pod, которые кластер может поддерживать. Также следует включить один дополнительный узел для операций обновления. Количество узлов будет равно n + number-of-additional-scaled-nodes-you-anticipate + 1.

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

План IP-адреса для кластера AKS содержит виртуальную сеть, по крайней мере одну подсеть для узлов и контейнеров pod, а также диапазон адресов службы Kubernetes.

Диапазон адресов / ресурс Azure	Установления размера и ограничения
Виртуальная сеть	Виртуальная сеть Azure может достигать размера /8, но ограничиваться 65 536 настроенными IP-адресами. Прежде чем настраивать диапазон адресов, учтите все требования к сети, в том числе взаимодействие со службами в других виртуальных сетях. Например, если настроить слишком большой диапазон адресов, могут возникнуть проблемы из-за перекрытия других диапазонов адресов в сети.
Подсеть	Подсеть должна быть достаточно большой, чтобы разместить узлы, контейнеры pod и все ресурсы Kubernetes и Azure, которые могут быть выделены в кластере. Например, если развертывается внутренний Azure Load Balancer, его внешние IP-адреса выделяются из подсети кластера, а не из публичных IP-адресов. При выборе размера подсети следует также учитывать операции обновления учетной записи и будущие потребности в масштабировании. Для вычисления минимального размера подсети, включая дополнительный узел для операции обновления, используйте следующую формулу: `(number of nodes + 1) + ((number of nodes + 1) * maximum pods per node that you configure)` Пример для кластера из 50 узлов: `(51) + (51 * 30 (default)) = 1,581` (/21 или больше) Пример для кластера из 50 узлов, в котором предусмотрено увеличение масштаба на 10 дополнительных узлов: `(61) + (61 * 30 (default)) = 1,891` (/21 или больше) Если не указать максимальное число контейнеров pod на каждом узле при создании кластера, оно будет иметь значение 30. Минимальное число требуемых IP-адресов на основе этого значения. При расчете минимального числа требуемых IP-адресов на другое максимальное значение см. раздел Настройка максимального числа контейнеров pod на каждом узле, чтобы присвоить это значение при развертывании кластера.
Диапазон адресов службы Kubernetes	Этот диапазон не должен использоваться элементом виртуальной сети или элементом, подключенным к ней. Адрес службы CIDR должен иметь размер меньше /12. Этот диапазон можно повторно использовать в разных кластерах AKS.
IP-адрес службы доменных имен (DNS) Kubernetes	IP-адрес в диапазоне адресов службы Kubernetes, который будет использоваться для обнаружения службы кластеров. Не используйте первый IP-адрес своего диапазона адресов. Первый адрес в диапазоне подсети используется для адреса kubernetes.default.svc.cluster.local.
Адрес моста Docker	Сетевой адрес моста Docker представляет сетевой адрес моста по умолчанию docker0, который имеется во всех установках Docker. Хотя мост docker0 не используется непосредственно кластерами AKS или модулями pod, необходимо задать этот адрес, чтобы обеспечить поддержку таких сценариев, как сборка Docker в кластере AKS. Необходимо выбрать CIDR для сетевого адреса моста Docker, так как в противном случае Docker выберет подсеть автоматически, что может вызвать конфликт с другими адресами CIDR. Нужно выбрать диапазон адресов, который не конфликтует с остальными адресами CIDR в ваших сетях, включая CIDR службы кластера и CIDR модуля pod. По умолчанию — 172.17.0.1/16. Этот диапазон можно повторно использовать в разных кластерах AKS.

Максимальное число контейнеров pod на узле

Максимальное число модулей pod на каждом узле в кластере AKS — 250. Максимальное количество контейнеров pod по умолчанию для каждого узла зависит от сети kubenet, Azure CNI и метода развертывания кластера.

Метод развертывания	По умолчанию Kubenet	По умолчанию Azure CNI	Настройка при развертывании
Azure CLI	110	30	Да (до 250)
Шаблон Resource Manager	110	30	Да (до 250)
Портал	110	110 (настраивается на вкладке "Пулы узлов")	Да (до 250)

Настройка максимального числа. Новые кластеры

Вы можете настроить максимальное число модулей pod на узел только во время развертывания кластера. Можно задать максимальное значение 250 pod на узел.

Если вы не укажете значение maxPods при создании пулов узлов, то будет применено значение по умолчанию для Azure CNI, равное 30.

Минимальное значение максимального числа модулей pod на узел применяется, чтобы обеспечить необходимое пространство для системных модулей pod, критически важных для работоспособности кластера. Минимальное значение максимального числа модулей pod на узел равно 10, но только если в конфигурации каждого пула узлов имеется место для не менее 30 модулей pod. Например, чтобы задать для максимального числа модулей pod на узел минимальное значение (10), требуется, чтобы каждый пул узлов содержал не менее 3 узлов. Это требование распространяется на каждый создаваемый пул узлов. Поэтому, если задано максимальное число модулей pod на узел, равное 10, то каждый последующий пул узлов должен содержать по крайней мере 3 узла.

Сеть	Минимальные	Максимум
Azure CNI	10	250
Kubenet	10	250

Примечание

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

Azure CLI. Укажите аргумент --max-pods при развертывании кластера с помощью команды az aks create. Максимальное значение — 250.
Шаблон Resource Manager. Укажите свойство maxPods в объекте ManagedClusterAgentPoolProfile при развертывании кластера с шаблоном Resource Manager. Максимальное значение — 250.
Портал Azure. Изменение Max pods per node поля в параметрах пула узлов при создании кластера или добавлении нового пула узлов.

Настройка максимального числа. Имеющиеся кластеры

Значение параметра maxPod на узел можно определить при создании пула узлов. Если необходимо увеличить значение maxPod на узел в существующем кластере, добавьте новый пул узлов с необходимым значением maxPod. После переноса модулей pod в новый пул удалите старый пул. При удалении каких-либо старых пулов из кластера убедитесь, что вы задаете режимы пула узлов, как предписывает документ о системных пулах узлов.

Параметры развертывания

При создании кластера AKS для сети Azure CNI можно настроить следующие параметры.

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

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

Подключаемый модуль сети Azure. При использовании подключаемого модуля сети Azure внутренняя служба балансировки нагрузки с параметром externalTrafficPolicy=Local недоступна из виртуальных машин с IP-адресом в диапазоне CIDR кластера, который не принадлежит к кластеру AKS.

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

Должен быть за пределами диапазона IP-адресов виртуальной сети вашего кластера.
Не должен пересекаться с диапазоном других виртуальных сетей, с которыми связан кластер виртуальной сети.
не должен перекрываться с какими-либо локальными IP-адресами.
Не должен быть в диапазонах 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 и 192.0.2.0/24.

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

IP-адрес службы DNS Kubernetes — IP-адрес службы DNS кластера. Этот адрес должен находиться в пределах диапазона адресов службы Kubernetes. Не используйте первый IP-адрес своего диапазона адресов. Первый адрес в диапазоне подсети используется для адреса kubernetes.default.svc.cluster.local.

Адрес моста Docker. Сетевой адрес моста Docker представляет сетевой адрес моста по умолчанию docker0, который присутствует во всех установленных экземплярах Docker. Хотя мост docker0 не используется непосредственно кластерами AKS или модулями pod, необходимо задать этот адрес, чтобы обеспечить поддержку таких сценариев, как сборка Docker в кластере AKS. Необходимо выбрать CIDR для сетевого адреса моста Docker, так как в противном случае Docker выберет подсеть автоматически, что может вызвать конфликт с другими адресами CIDR. Нужно выбрать диапазон адресов, который не конфликтует с остальными адресами CIDR в ваших сетях, включая CIDR службы кластера и CIDR модуля pod.

Настройка сети с помощью интерфейса командной строки

При создании кластера AKS с помощью Azure CLI вы можете также настроить сеть Azure CNI. Используйте указанные ниже команды для создания кластера AKS с включенной сетью Azure CNI.

Сначала получите идентификатор ресурса существующей подсети, к которой будет присоединен кластер AKS.

$ az network vnet subnet list \
    --resource-group myVnet \
    --vnet-name myVnet \
    --query "[0].id" --output tsv

/subscriptions/<guid>/resourceGroups/myVnet/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/default

Используйте команду az aks create с аргументом --network-plugin azure для создания кластера с функциями сетевого взаимодействия уровня "Расширенный". Измените значение --vnet-subnet-id, указав идентификатор подсети, полученный на предыдущем шаге.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --network-plugin azure \
    --vnet-subnet-id <subnet-id> \
    --docker-bridge-address 172.17.0.1/16 \
    --dns-service-ip 10.2.0.10 \
    --service-cidr 10.2.0.0/24 \
    --generate-ssh-keys

Настройка сети с помощью портала

На следующем снимке экрана на портале Azure показан пример настройки этих параметров во время создания кластера AKS.

Advanced networking configuration in the Azure portal

Динамическое распределение IP-адресов и расширенная поддержка подсетей

Недостатком традиционного решения CNI является нехватка IP-адресов pod, возникающая по мере роста кластера AKS, что приводит к необходимости перестроения всего кластера в более крупной подсети. Новая функция динамического выделения IP-адресов в Azure CNI устраняет эту проблему, выделяя IP-адреса pod из подсети, отдельной от подсети, в которой размещен кластер AKS. Так вы получите следующие преимущества:

Улучшенное использование IP-адресов. IP-адреса выделяются динамически для модулей pod кластера из подсети pod. Это обеспечивает более эффективное использование IP-адресов в кластере по сравнению с традиционным решением CNI, которое выполняет статическое выделение IP-адресов для каждого узла.
Масштабируемость и гибкость. Подсети узлов и модулей pod можно масштабировать независимо друг от друга. Одну и ту же подсеть pod можно совместно использовать в нескольких пулах узлов кластера или в нескольких кластерах AKS, развернутых в одной виртуальной сети. Можно также настроить отдельную подсеть pod для пула узлов.
Высокая производительность. Так как для модулей pod назначаются IP-адреса виртуальной сети, они имеют прямое подключение к другим модулям pod и ресурсам кластера в этой виртуальной сети. Такое решение обеспечивает поддержку очень больших кластеров без снижения производительности.
Отдельные политики виртуальной сети для модулей pod. Так как модули pod размещаются в отдельной подсети, для них можно настроить отдельные политики виртуальной сети, отличные от политик узлов. Это позволяет реализовать многие практичные сценарии, в том числе разрешение подключения к Интернету только для модулей pod, а не для узлов, исправление исходного IP-адреса pod в пуле узлов с помощью NAT виртуальной сети и использование групп безопасности сети для фильтрации трафика между пулами узлов.
Политики сети Kubernetes. Политики сети Azure и Calico вполне совместимы с этим новым решением.

Дополнительные требования

Примечание

При использовании динамического выделения IP-адресов не поддерживается предоставление приложения в качестве службы Приватного канала с помощью службы Load Balancer Kubernetes.

Действуют предварительные требования, указанные выше для Azure CNI, но существует несколько дополнительных ограничений:

Поддерживаются только кластеры узлов и пулы узлов Linux.
Подсистема AKS и пользовательские кластеры (DIY) не поддерживаются.
Azure CLI версии 2.37.0 или более поздней.

Планирование IP-адресации

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

Планирование IP-адресов для служб Kubernetes и моста Docker остается без изменений.

Максимальное число модулей pod на узел в кластере с динамическим выделением IP-адресов и расширенной поддержкой подсетей

Значения числа модулей pod на узел при использовании Azure CNI с динамическим выделением IP-адресов немного отличаются по сравнению с традиционным решением CNI.

CNI	По умолчанию	Настройка при развертывании
Традиционное решение Azure CNI	30	Да (до 250)
Azure CNI с динамическим выделением IP-адресов	250	Да (до 250)

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

Дополнительные параметры развертывания

Описанные выше параметры развертывания по-прежнему являются допустимыми, кроме одного исключения:

параметр subnet теперь указывает на подсеть, связанную с узлами кластера.
Дополнительный параметр pod subnet позволяет указать подсеть, IP-адреса которой будут динамически выделяться для модулей pod.

Настройка сети с динамическим выделением IP-адресов и расширенной поддержкой подсетей с помощью интерфейса командной строки

Использование динамического выделения IP-адресов и расширенной поддержки подсетей в кластере аналогично методу по умолчанию, применяемому для настройки кластера Azure CNI. В следующем примере показано, как создать виртуальную сеть с подсетью для узлов и подсетью для модулей pod, а также создать кластер, использующий Azure CNI с динамическим выделением IP-адресов и расширенной поддержкой подсетей. Обязательно замените переменные, например $subscription, собственными значениями.

Сначала создайте виртуальную сеть с двумя подсетями.

resourceGroup="myResourceGroup"
vnet="myVirtualNetwork"
location="westcentralus"

# Create the resource group
az group create --name $resourceGroup --location $location

# Create our two subnet network 
az network vnet create -g $resourceGroup --location $location --name $vnet --address-prefixes 10.0.0.0/8 -o none 
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name nodesubnet --address-prefixes 10.240.0.0/16 -o none 
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name podsubnet --address-prefixes 10.241.0.0/16 -o none

Затем создайте кластер, указав подсеть узла с помощью --vnet-subnet-id и подсеть pod с помощью --pod-subnet-id.

clusterName="myAKSCluster"
subscription="aaaaaaa-aaaaa-aaaaaa-aaaa"

az aks create -n $clusterName -g $resourceGroup -l $location \
  --max-pods 250 \
  --node-count 2 \
  --network-plugin azure \
  --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/nodesubnet \
  --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/podsubnet

Добавление пула узлов

При добавлении пула узлов укажите подсеть узла с помощью --vnet-subnet-id и подсеть pod с помощью --pod-subnet-id. В следующем примере создаются две подсети, которые можно будет указать при создании нового пула узлов.

az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name node2subnet --address-prefixes 10.242.0.0/16 -o none 
az network vnet subnet create -g $resourceGroup --vnet-name $vnet --name pod2subnet --address-prefixes 10.243.0.0/16 -o none 

az aks nodepool add --cluster-name $clusterName -g $resourceGroup  -n newnodepool \
  --max-pods 250 \
  --node-count 2 \
  --vnet-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/node2subnet \
  --pod-subnet-id /subscriptions/$subscription/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnet/subnets/pod2subnet \
  --no-wait

Часто задаваемые вопросы

Следующие вопросы и ответы относятся к конфигурации сети Azure CNI.

Можно ли развернуть виртуальные машины в подсети моего кластера?

Да.
Какой исходный IP-адрес определят внешние системы для трафика, источником которого является pod с поддержкой Azure CNI?

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

Да, политика сети Kubernetes доступна в AKS. Чтобы приступить к работе, ознакомьтесь со статьей Защита трафика между группами pod с использованием политик сети в Службе Azure Kubernetes (AKS).
Можно ли настроить максимальное число контейнеров pod, развертываемых на узел?

Да, при развертывании кластера с помощью Azure CLI или шаблона Resource Manager. См. статью Конфигурация сети в службе Azure Kubernetes (AKS).

Невозможно изменить максимальное количество контейнеров pod в узле в имеющемся кластере.
Как настроить дополнительные свойства для подсети, созданной во время создания кластера AKS? Например, конечные точки службы.

Полный список свойств для виртуальной сети и подсетей, создаваемых во время создания кластера AKS, можно настроить на странице стандартной конфигурации виртуальной сети на портале Azure.
Можно ли использовать другую подсеть в виртуальной сети кластера длядиапазона адресов службы Kubernetes?

Не рекомендуется, но эта конфигурация возможна. Диапазон адресов службы — это набор виртуальных IP-адресов, которые Kubernetes присваивает внутренним службам в кластере. Сеть Azure не видит адреса в диапазоне IP-адресов службы кластера Kubernetes. Из-за этого позже возможно создать подсеть в виртуальной сети кластера, которая пересекается с диапазоном адресов службы. При возникновении такого пересекания Kubernetes может присвоить службе IP-адрес, который уже используется другим ресурсом в подсети, что приводит к непредсказуемому поведению или сбоям. Убедившись, что диапазон адресов используется за пределами виртуальной сети кластера, можно избежать такого риска пересечений.

Вопросы и ответы о динамическом выделении IP-адресов и расширенной поддержке подсетей (предварительная версия)

Ниже приведены вопросы и ответы о настройке сети Azure CNI при использовании динамического выделения IP-адресов и расширенной поддержки подсетей.

Можно ли назначить несколько подсетей pod для кластера или пула узлов?

Для кластера или пула узлов можно назначить только одну подсеть. Однако несколько кластеров или пулов узлов могут совместно использовать одну подсеть.
Можно ли назначить подсети pod из другой виртуальной сети?

Нет, подсеть pod должна относиться к той же виртуальной сети, что и кластер.
Могут ли некоторые пулы узлов в кластере использовать традиционное решение CNI, тогда как другие используют новое решение CNI?

Весь кластер должен использовать только один тип CNI.

Дальнейшие шаги

Узнайте больше о сетевом взаимодействии в AKS из следующих статей: