Настройка подсети Pod в Azure CNI — выделение статических блоков и расширенная поддержка подсетей в службе Azure Kubernetes (AKS)

Ограничение подсети Pod Azure CNI — динамическое распределение IP-адресов заключается в масштабируемости размера подсети Pod за пределы /16. Даже с большой подсетью крупные кластеры по-прежнему могут быть ограничены 65 тысячами подов из-за ограничения адресного сопоставления в Azure. Статическое выделение блоков в подсети Pod с использованием Azure CNI решает эту проблему, назначая блоки CIDR узлам, а не отдельным IP-адресам.

Так вы получите следующие преимущества:

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

В этой статье показано, как использовать подсеть Pod Azure CNI — выделение статического блока и расширенную поддержку подсети в AKS.

Prerequisites

• Ознакомьтесь с предварительными условиями для настройки базовой сети Azure CNI в AKS, так как к этой статье применяются те же предварительные требования.

• Просмотрите параметры развертывания для настройки базовой сети Azure CNI в AKS, так как применяются те же параметры.

• Механизм AKS и кластеры ручной сборки не поддерживаются.

• Версия Azure CLI 2.75.0 или более поздняя

• Если у вас есть существующий кластер, необходимо включить Аналитику контейнеров для мониторинга использования IP-подсети. Вы можете включить Аналитику az aks enable-addons контейнеров с помощью команды, как показано в следующем примере:

  az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>
  

Limitations

Ниже приведены некоторые ограничения использования подсети Pod Pod Azure CNI — статического выделения блоков:

• Минимальная версия Kubernetes: 1.28
• Максимальный размер подсети, поддерживаемый x.x.x.x/12 ~ 1 млн IP-адресов
• Для каждой подсети можно использовать только один режим операции. Если подсеть использует режим выделения статических блоков, он не может использовать динамический режим выделения IP-адресов в другом кластере или пуле узлов с одной подсетью и наоборот.
• Поддерживается только в новых кластерах или при добавлении пулов узлов с другой подсетью в существующие кластеры. Миграция или обновление существующих кластеров или пулов узлов не поддерживается.
• Во всех блоках CIDR, назначенных узлу в пуле узлов, один IP-адрес будет выбран в качестве основного IP-адреса узла. Таким образом, для сетевых администраторов при выборе значения --max-pods попробуйте использовать приведенный ниже расчет, чтобы лучше обслуживать ваши нужды и иметь оптимальное использование IP-адресов в подсети.
  max_pods = (N * 16) - 1
  где N является любым положительным целым числом и N > 0

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

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

В этом сценарии блоки CIDR /28 (16 IP-адресов) выделяются узлам на основе вашей конфигурации '--max-pods' для пула узлов, которая определяет максимальное количество подов на узел. 1 IP-адрес зарезервирован на каждом узле со всех доступных IP-адресов на этом узле для внутренних целей.

Таким образом, при определении и планировании IP-адресов важно задать конфигурацию "--max-pods", и ее можно оптимально вычислить следующим образом: max_pods_per_node = (16 * N) - 1 где N является любым положительным целым числом больше 0

Идеальным значением без потерь IP-адресов было бы требование, чтобы значение max pods соответствовало приведенному выше выражению.

• Пример 1: max_pods = 30, блоки CIDR, выделенные для каждого узла = 2, общее количество доступных IP-адресов для pod = (16 * 2) - 1 = 32 - 1 = 31, потеря IP на узел = 31 - 30 = 1 [Низкая потеря — допустимый случай]
• Пример 2: max_pods = 31, выделенные CIDR-блоки на узел = 2, общее количество IP-адресов, доступных для pods = (16 * 2) - 1 = 32 – 1 = 31, IP-потери на узел = 31 – 31 = 0 [Идеальный случай]
• Пример 3: max_pods = 32, CIDR-блоки, выделенные на узел = 3, общее количество IP-адресов, доступных для pod = (16 * 3) - 1 = 48 - 1 = 47, отход IP на узел = 47 - 32 = 15 [Высокий перерасход — не рекомендуется]

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

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

Параметры развертывания для настройки базовых сетей Azure CNI в AKS являются допустимыми, за исключением следующих вариантов:

• Теперь параметр идентификатора подсети виртуальной сети ссылается на подсеть, связанную с узлами кластера.
• Идентификатор подсети пода используется для указания подсети, IP-адреса которой будут статически или динамически выделены подам в пуле узлов.
• Параметр режима выделения IP-адресов pod указывает, следует ли использовать DynamicIndividual (динамическое выделение IP-адресов) или StaticBlock (выделение статических блоков).

Настройка сети со статическим выделением блоков CIDR и расширенной поддержкой подсети — Azure CLI

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

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

resourceGroup="myResourceGroup"
vnet="myVirtualNetwork"
location="myRegion"

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

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

Создайте кластер, ссылаясь на подсеть узла, используя --vnet-subnet-id, на подсеть pod, используя --pod-subnet-id, с помощью --pod-ip-allocation-mode для определения режима выделения IP-адресов, и включите надстройку мониторинга.

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

az aks create \
    --name $clusterName \
    --resource-group $resourceGroup \
    --location $location \
    --max-pods 250 \
    --node-count 2 \
    --network-plugin azure \
    --pod-ip-allocation-mode StaticBlock \
    --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 \
    --enable-addons monitoring \
    --generate-ssh-keys

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

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

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 \
    --pod-ip-allocation-mode StaticBlock \
    --no-wait

Миграция из подсети Pod — динамическое выделение IP-адресов в подсеть Pod — выделение статического блока

Если у вас есть существующий кластер AKS, использующий динамическое выделение IP-адресов для подсети pod и хотите перейти в подсеть Pod — статический блок выделения, выполните следующие действия.

Этапы миграции

1. Планирование использования новой подсети для пулов агентов статического блока

   • Создайте новую подсеть в существующем VNet, которая будет выделена для режима статического блока.
   • Убедитесь, что размер подсети следует рекомендациям по планированию, описанным в разделе "Планирование IP-адресации"

2. Добавление пула агентов в существующий кластер с режимом статического блока и новой подсетью

   • Используйте команду az aks nodepool add для создания нового пула узлов со статическим выделением блоков.
   • Используйте --pod-subnet-id для новой подсети и установите --pod-ip-allocation-mode в StaticBlock

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

   • Использование kubectl cordon для пометки существующих узлов как незапланированных
   • Постепенный отток нагрузки из старого пула узлов в пул узлов со статическими блоками

4. После перемещения всех рабочих нагрузок в новый пул агентов удалите существующий нестатический пул агентов.

   • Проверка успешного выполнения всех рабочих нагрузок в новом пуле узлов
   • Удаление старого пула узлов с помощью az aks nodepool delete

Часто задаваемые вопросы по статическому выделению блоков CIDR и расширенной поддержке подсетей

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

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

• Можно ли назначить подсети Pod из совершенно другой виртуальной сети?

  Нет, подсеть pod должна быть из той же виртуальной сети, что и кластер.

• Могут ли некоторые пулы узлов в кластере с подсетевым IPAM для pod использовать динамическое выделение IP-адресов, а другие использовать новое выделение статического блока?

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

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

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

• Используйте статический IP-адрес с балансировщиком нагрузки Azure Kubernetes Service (AKS)
• Использование внутреннего балансировщика нагрузки в Службе Kubernetes Azure (AKS)
• Использование надстройки маршрутизации приложений в Azure Kubernetes Service (AKS)