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

  • Статья

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

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

Общие сведения о сети overlay

В сети Overlay только узлы кластера Kubernetes назначаются ip-адресам из подсетей. Модули Pod получают IP-адреса из частного CIDR, предоставленного во время создания кластера. Каждому узлу назначается диапазон адресов /24 из одного и того же диапазона CIDR. Дополнительные узлы, созданные при горизонтальном масштабировании кластера, автоматически получают /24 адресные пространства из того же CIDR. Azure CNI назначает IP-адреса объектам pod из этого диапазона адресов /24.

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

Схема с двумя узлами с тремя модулями pod, работающими в сети наложения. Трафик pod к конечным точкам за пределами кластера направляется через NAT.

Обмен данными с конечными точками за пределами кластера, такими как локальные и пиринговые виртуальные сети, происходит с помощью IP-адреса узла через NAT. Azure CNI преобразует исходный IP-адрес (наложенный IP-адрес pod) трафика на первичный IP-адрес виртуальной машины, который позволяет стеку сетей Azure направлять трафик в место назначения. Конечные точки за пределами кластера не могут напрямую подключаться к объектам pod. Необходимо опубликовать приложение pod как службу Load Balancer Kubernetes, чтобы сделать ее доступной в виртуальной сети.

Вы можете предоставить исходящее подключение к Интернету для модулей pod Overlay с помощью подсистемы балансировки нагрузки SKU уровня "Стандартный" или управляемого шлюза NAT. Также можно управлять исходящим трафиком, перенаправляя его в брандмауэр с помощью определяемых пользователем маршрутов в подсети кластера.

Вы можете настроить подключение входящего трафика к кластеру с помощью контроллера входящего трафика, например маршрутизации приложений Nginx или HTTP. Невозможно настроить подключение входящего трафика с помощью шлюза приложение Azure. Дополнительные сведения см. в разделе "Ограничения" с наложением Azure CNI.

Различия между Kubenet и Наложением Azure CNI

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

Площадь Наложение Azure CNI Kubenet
Масштаб кластера 5000 узлов и 250 модулей pod/node 400 узлов и 250 объектов pod/узел
Сетевая конфигурация Простой— не требуется дополнительных конфигураций для сети pod Сложная — для сети с объектами pod требуются таблицы маршрутов и определяемые пользователем маршруты в подсети кластера
Производительность подключений pod Производительность наравне с виртуальными машинами в виртуальной сети Дополнительный прыжок добавляет задержку
Сетевые политики Kubernetes Политики сети Azure, Calico, Cilium Calico
Поддерживаемые платформы ОС Linux и Windows Server 2022, 2019 только Linux.

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

  • Узлы кластера. При настройке кластера AKS убедитесь, что подсети виртуальной сети достаточно места для дальнейшего масштабирования. Вы можете назначить каждому пулу узлов выделенной подсети. /24Подсеть может соответствовать до 251 узлов, так как первые три IP-адреса зарезервированы для задач управления.
  • Pods: решение overlay назначает адресное /24 пространство для модулей pod на каждом узле из частного CIDR, указанного во время создания кластера. Размер /24 является фиксированным и не может быть увеличен или уменьшен. На узле можно запустить до 250 объектов pod. При планировании адресного пространства pod убедитесь, что частный CIDR достаточно велик, чтобы предоставить /24 адресные пространства для новых узлов для поддержки будущего расширения кластера.
    • При планировании пространства IP-адресов для модулей pod следует учитывать следующие факторы:
      • Один и тот же диапазон CIDR для pod можно использовать в нескольких независимых кластерах AKS в одной виртуальной сети.
      • Диапазон CIDR для pod не должен перекрываться с диапазоном подсети кластера.
      • Пространство CIDR pod не должно перекрываться напрямую подключенными сетями (например, пиринг виртуальных сетей, ExpressRoute или VPN). Если внешний трафик имеет исходные IP-адреса в диапазоне podCIDR, он должен передаваться в не перекрывающийся IP-адрес через SNAT для взаимодействия с кластером.
  • Диапазон адресов службы Kubernetes. Размер диапазона адресов CIDR для службы зависит от количества создаваемых служб кластера. Он должен быть меньше /12. Этот диапазон не должен перекрываться с диапазоном CIDR pod, диапазоном подсети кластера и диапазоном IP-адресов, используемым в одноранговых виртуальных сетях и локальных сетях.
  • IP-адрес службы DNS Kubernetes: этот IP-адрес находится в диапазоне адресов службы Kubernetes, используемых обнаружением службы кластера. Не используйте первый IP-адрес в диапазоне адресов, так как этот адрес используется для kubernetes.default.svc.cluster.local адреса.

Группы безопасности сети

Pod для трафика pod с помощью Наложения Azure CNI не инкапсулируется, а правила группы безопасности сети подсети применяются. Если группа безопасности сети подсети содержит правила запрета, влияющие на трафик CIDR pod, убедитесь, что существуют следующие правила, чтобы обеспечить правильную функциональность кластера (помимо всех требований исходящего трафика AKS):

  • Трафик от CIDR узла к узлу CIDR на всех портах и протоколах
  • Трафик от CIDR узла к CIDR pod на всех портах и протоколах (необходимых для маршрутизации трафика службы)
  • Трафик из CIDR pod в ciDR pod на все порты и протоколы (необходимый для pod для pod и pod в трафик обслуживания, включая DNS)

Трафик из модуля pod в любое место за пределами блока CIDR pod использует SNAT для установки исходного IP-адреса в IP-адрес узла, на котором выполняется модуль pod.

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

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

Максимальное количество объектов pod на узел можно настроить во время создания кластера или при добавлении нового пула узлов. Значение по умолчанию для наложения Azure CNI равно 250. Максимальное значение, которое можно указать в наложении Azure CNI, равно 250, а минимальное значение — 10. Максимальное число объектов pod на узел, указанное во время создания пула узлов, применяется только к узлам в этом пуле.

Выбор модели сети

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

Используйте сеть наложения, когда:

  • Вы хотите масштабировать до большого количества модулей pod, но имеют ограниченное пространство IP-адресов в виртуальной сети.
  • Большая часть обмена данными между объектами pod происходит в пределах кластера.
  • Вам не требуются расширенные возможности AKS, такие как виртуальные узлы.

Используйте традиционный параметр виртуальной сети, если:

  • У вас есть достаточный диапазон IP-адресов.
  • Объекты pod обмениваются данными в основном с ресурсами за пределами кластера.
  • Ресурсы за пределами кластера должны напрямую обращаться к объектам pod.
  • Вам требуются расширенные возможности AKS, такие как виртуальные узлы.

Ограничения, связанные с наложением Azure CNI

Наложение Azure CNI имеет следующие ограничения:

  • Нельзя использовать Шлюз приложений в качестве контроллера входящего трафика (AGIC) для кластера наложения.
  • Группы доступности виртуальных машин (VMAS) не поддерживаются для наложения.
  • Виртуальные машины серии DCsv2 нельзя использовать в пулах узлов. Чтобы удовлетворить требования к конфиденциальным вычислениям, рекомендуется использовать конфиденциальные виртуальные машины серии DCasv5 или DCadsv5.
  • Если вы используете собственную подсеть для развертывания кластера, имена подсети, виртуальной сети и группы ресурсов, содержащей виртуальную сеть, должны быть 63 символами или меньше. Это связано с тем, что эти имена будут использоваться в качестве меток в рабочих узлах AKS и поэтому подвергаются правилам синтаксиса меток Kubernetes.

Настройка кластеров наложения

Примечание.

Для использования --network-plugin-mode аргумента необходимо использовать CLI версии 2.48.0 или более поздней. Для Windows необходимо установить последнее расширение Azure CLI aks-preview и следовать приведенным ниже инструкциям.

Создайте кластер с помощью наложения Azure CNI с помощью az aks create команды. Обязательно используйте аргумент --network-plugin-mode для указания кластера наложения. Если CIDR pod не указан, AKS назначает пространство по умолчанию: viz. 10.244.0.0/16

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks create -n $clusterName -g $resourceGroup \
  --location $location \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16

Добавление нового узла в выделенную подсеть

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

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"
nodepoolName="newpool1"
subscriptionId=$(az account show --query id -o tsv)
vnetName="yourVnetName"
subnetName="yourNewSubnetName"
subnetResourceId="/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Network/virtualNetworks/$vnetName/subnets/$subnetName"
az aks nodepool add  -g $resourceGroup --cluster-name $clusterName \
  --name $nodepoolName --node-count 1 \
  --mode system --vnet-subnet-id $subnetResourceId

Обновление существующего кластера до наложения CNI

Примечание.

Можно обновить существующий кластер Azure CNI на наложение, если кластер соответствует следующим критериям:

  • Кластер находится в Kubernetes версии 1.22+.
  • Не использует функцию динамического выделения IP-адресов pod.
  • Не включает политики сети. Подсистема сетевой политики может быть удалена до обновления, см. статью "Удаление диспетчера сетевых политик Azure" или "Калифорния"
  • Не использует пулы узлов Windows с docker в качестве среды выполнения контейнера.

Примечание.

Так как домен маршрутизации еще не поддерживается для ARM, на узлах процессора на основе ARM (ARM64) не поддерживается наложения CNI.

Примечание.

Обновление существующего кластера до наложения CNI является необратимым процессом.

Предупреждение

До сборки ОС Windows 20348.1668 было ограничение вокруг модулей pod Windows Overlay неправильно SNATing пакетов из сетевых модулей pod узла, которые имели более вредный эффект для кластеров, обновляющихся до overlay. Чтобы избежать этой проблемы, используйте сборку ОС Windows, превышающую или равной 20348.1668.

Предупреждение

Если вы используете настраиваемую конфигурацию агента azure-ip-masq-agent для включения дополнительных диапазонов IP-адресов, которые не должны отправлять пакеты SNAT из модулей pod, обновление до Azure CNI Overlay может нарушить подключение к этим диапазонам. IP-адреса pod из пространства наложения не будут доступны ни в чем за пределами узлов кластера. Кроме того, для достаточно старых кластеров может быть ConfigMap, оставшееся от предыдущей версии azure-ip-masq-agent. Если этот объект ConfigMap с именем azure-ip-masq-agent-config, существует и не намеренно находится на месте, его следует удалить перед выполнением команды обновления. Если не используется настраиваемая конфигурация config-ip-masq-agent, то только azure-ip-masq-agent-config-reconciled ConfigMap должна существовать в отношении конфигурации Config ip-masq-agent Azure Карты и она будет обновляться автоматически во время процесса обновления.

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

Обновление кластера Azure CNI

Обновите существующий кластер Azure CNI, чтобы использовать наложение az aks update с помощью команды.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin-mode overlay \
--pod-cidr 192.168.0.0/16

Параметр --pod-cidr требуется при обновлении из устаревшей CNI, так как модули pod должны получать IP-адреса из нового пространства наложения, которое не перекрывается существующей подсетью узла. CiDR pod также не может перекрываться с любым адресом виртуальной сети пулов узлов. Например, если адрес виртуальной сети равен 10.0.0.0/8, а узлы находятся в подсети 10.240.0.0/16, --pod-cidr невозможно перекрываться с 10.0.0.0/8 или существующей службой CIDR в кластере.

Обновление кластера Kubenet

Обновите существующий кластер Kubenet, чтобы использовать наложение az aks update Azure CNI с помощью команды.

clusterName="myOverlayCluster"
resourceGroup="myResourceGroup"
location="westcentralus"

az aks update --name $clusterName \
--resource-group $resourceGroup \
--network-plugin azure \
--network-plugin-mode overlay

Так как кластер уже использует частный CIDR для модулей pod, которые не перекрываются с пространством IP-адресов виртуальной сети, вам не нужно указывать --pod-cidr параметр, а CIDR pod останется неизменным.

Примечание.

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

Сеть с двумя стеками

Кластеры AKS можно развернуть в режиме двойного стека при использовании сети Overlay и виртуальной сети Azure с двойным стеком. В этой конфигурации узлы получают адреса IPv4 и IPv6 из подсети виртуальной сети Azure. Модули pod получают адреса IPv4 и IPv6 из логически отличного адресного пространства в подсеть узлов виртуальной сети Azure. Преобразование сетевых адресов (NAT) настраивается таким образом, чтобы модули pod могли получить доступ к ресурсам в виртуальной сети Azure. Исходный IP-адрес трафика — преобразование сетевых адресов (NAT) в основной IP-адрес узла того же семейства (IPv4-адреса к IPv4 и IPv6-адреса к IPv6).

Необходимые компоненты

  • Необходимо установить Azure CLI 2.48.0 или более поздней версии.
  • Kubernetes версии 1.26.3 или более поздней.

Ограничения

Следующие функции не поддерживаются в сети с двумя стеками:

  • Windows Nodepools
  • Сетевые политики Azure
  • Сетевые политики Calico
  • Шлюз NAT
  • надстройка виртуальных узлов.

Развертывание кластера AKS с двумя стеками

Для поддержки кластеров с двумя стеками предоставляются следующие атрибуты:

  • --ip-families: принимает разделенный запятыми список семейств IP-адресов для включения в кластере.
    • Поддерживаются только ipv4 или ipv4,ipv6 поддерживаются.
  • --pod-cidrs: принимает разделенный запятыми список диапазонов IP-адресов нотации CIDR для назначения IP-адресов pod из.
    • Количество и порядок диапазонов в этом списке должны соответствовать значению, указанному в --ip-families.
    • Если значения не заданы, используется значение 10.244.0.0/16,fd12:3456:789a::/64 по умолчанию.
  • --service-cidrs: принимает разделенный запятыми список диапазонов IP-адресов нотации CIDR для назначения IP-адресов служб.
    • Количество и порядок диапазонов в этом списке должны соответствовать значению, указанному в --ip-families.
    • Если значения не заданы, используется значение 10.0.0.0/16,fd12:3456:789a:1::/108 по умолчанию.
    • Подсеть IPv6, назначенная --service-cidrs, не может быть больше чем /108.

Создание кластера AKS с двумя стеками

  1. Создайте группу ресурсов Azure для кластера с помощью команды [az group create][az-group-create].

    az group create -l <region> -n <resourceGroupName>

  2. Создайте кластер AKS с двумя стеками с помощью az aks create команды с заданным параметром --ip-familiesipv4,ipv6.

    az aks create -l <region> -g <resourceGroupName> -n <clusterName> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --ip-families ipv4,ipv6

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

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

Развертывание веб-сервера NGINX

Надстройка маршрутизации приложений — это рекомендуемый способ для входящего трафика в кластере AKS. Дополнительные сведения о надстройке маршрутизации приложений и примере развертывания приложения с помощью надстройки см. в разделе "Управляемый входящий трафик NGINX" с надстройкой маршрутизации приложений.

Предоставление рабочей нагрузки LoadBalancer через службу типов

Внимание

В настоящее время существует два ограничения , относящиеся к службам IPv6 в AKS.

  • Azure Load Balancer отправляет пробы работоспособности в пункты назначения IPv6 по адресу локального канала. В пулах узлов Linux Azure этот трафик нельзя перенаправить в pod, поэтому трафик, поступающий в службы IPv6, развернутые сбоем externalTrafficPolicy: Cluster . Службы IPv6 должны быть развернуты с externalTrafficPolicy: Localпомощью , что приводит kube-proxy к реагированию на пробу на узле.
  • До версии Kubernetes версии 1.27 только первый IP-адрес службы будет подготовлен для подсистемы балансировки нагрузки, поэтому служба двойного стека получает общедоступный IP-адрес для своего первого семейства IP-адресов. Чтобы предоставить службу двойного стека для одного развертывания, создайте две службы, предназначенные для одного селектора, один для IPv4 и один для IPv6. Это больше не ограничение в kubernetes 1.27 или более поздней версии.

  1. Предоставление развертывания NGINX с помощью kubectl expose deployment nginx команды.

    kubectl expose deployment nginx --name=nginx-ipv4 --port=80 --type=LoadBalancer'
kubectl expose deployment nginx --name=nginx-ipv6 --port=80 --type=LoadBalancer --overrides='{"spec":{"ipFamilies": ["IPv6"]}}'

    Вы получите выходные данные, показывающие, что службы были предоставлены.

    service/nginx-ipv4 exposed
service/nginx-ipv6 exposed

  2. После предоставления развертывания и LoadBalancer полной подготовки служб получите IP-адреса служб с помощью kubectl get services команды.

    kubectl get services

    NAME         TYPE           CLUSTER-IP               EXTERNAL-IP         PORT(S)        AGE
nginx-ipv4   LoadBalancer   10.0.88.78               20.46.24.24         80:30652/TCP   97s
nginx-ipv6   LoadBalancer   fd12:3456:789a:1::981a   2603:1030:8:5::2d   80:32002/TCP   63s

  3. Проверка функциональности с помощью веб-запроса командной строки из узла, поддерживающего IPv6. Azure Cloud Shell не поддерживает IPv6.

    SERVICE_IP=$(kubectl get services nginx-ipv6 -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
curl -s "http://[${SERVICE_IP}]" | head -n5

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>

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

Чтобы узнать, как использовать AKS с собственным подключаемым модулем сетевого интерфейса контейнера (CNI), см . статью "Создание собственного подключаемого модуля сетевого интерфейса контейнера (CNI).