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

Статья
08/02/2024

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

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

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

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

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

Примечание.

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

Ознакомьтесь с предварительными условиями для настройки базовой сети Azure CNI в AKS, так как к этой статье применяются те же предварительные требования.
Просмотрите параметры развертывания для настройки базовой сети Azure CNI в AKS, так как применяются те же параметры.
Подсистема AKS и кластеры DIY не поддерживаются.
Версия 2.37.0 Azure CLI или более поздняя с расширением aks-preview версии 2.0.0b2 или более поздней
Если у вас есть существующий кластер, необходимо включить Аналитику контейнеров для мониторинга использования IP-подсети. Вы можете включить Аналитику az aks enable-addons контейнеров с помощью команды, как показано в следующем примере:
Зарегистрируйте флаг функции уровня подписки для подписки: "Microsoft.ContainerService/AzureVnetScalePreview"
```
az aks enable-addons --addons monitoring --name <cluster-name> --resource-group <resource-group-name>
```

Ограничения

Ниже приведены некоторые ограничения использования статического блока 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

Доступность по регионам

Эта функция недоступна в следующих регионах:

Южная часть США
Восточная часть США 2
Западная часть США
Западная часть США 2

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

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

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

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

Идеальными значениями без значения ip-адреса не требуется максимальное значение pod для соответствия приведенному выше выражению.

Пример 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-адресов, доступных для модулей pod = (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 являются допустимыми с двумя исключениями:

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

Подготовка к работе

Если вы используете aks-preview Azure CLI, вам потребуется расширение. См . раздел "Установка aks-preview расширения Azure CLI".
При использовании ARM или REST API версия API AKS должна быть 2024-01-02-preview или более поздней.

Установка расширения Azure CLI `aks-preview`

aks-preview Установите расширение с помощью az extension add команды.
```
az extension add --name aks-preview
```
Обновите до последней версии расширения с помощью az extension update команды. Расширение должно иметь версию 2.0.0b2 или более поздней версии.
```
az extension update --name aks-preview
```

Регистрация флага компонента `AzureVnetScalePreview`

AzureVnetScalePreview Зарегистрируйте флаг компонента с помощью az feature register команды.
```
az feature register --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"
```
Через несколько минут отобразится состояние Registered (Зарегистрировано).
Проверьте состояние регистрации с помощью az feature show команды.
```
az feature show --namespace "Microsoft.ContainerService" --name "AzureVnetScalePreview"
```
Когда состояние отражает зарегистрировано, обновите регистрацию поставщика ресурсов Microsoft.ContainerService с помощью az provider register команды.
```
az provider register --namespace Microsoft.ContainerService
```

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

Использование статического выделения блоков CIDR в кластере аналогично методу по умолчанию для настройки кластера Azure CNI для динамического выделения IP-адресов. В следующем примере описывается создание виртуальной сети с подсетью для узлов и подсети для модулей pod и создание кластера, использующего Azure CNI со статическим выделением блоков CIDR. Обязательно замените переменные, такие как $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

Создайте кластер, ссылаясь на подсеть узла, используя подсеть pod, используя --vnet-subnet-id--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, используя режим выделения "--pod-ip-выделение". В следующем примере создаются две подсети, которые можно будет указать при создании нового пула узлов.

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

Статическое выделение блоков CIDR и расширенная подсеть поддерживают часто задаваемые вопросы

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

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

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

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

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

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

Поделиться через

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

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

Ограничения

Доступность по регионам

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

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

Подготовка к работе

Установка расширения Azure CLI `aks-preview`

Регистрация флага компонента `AzureVnetScalePreview`

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

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

Статическое выделение блоков CIDR и расширенная подсеть поддерживают часто задаваемые вопросы

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

Дополнительные ресурсы

Поделиться через

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

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

Ограничения

Доступность по регионам

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

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

Подготовка к работе

Установка расширения Azure CLI aks-preview

Регистрация флага компонента AzureVnetScalePreview

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

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

Статическое выделение блоков CIDR и расширенная подсеть поддерживают часто задаваемые вопросы

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

Дополнительные ресурсы

Установка расширения Azure CLI `aks-preview`

Регистрация флага компонента `AzureVnetScalePreview`