Подсеть Pod для сетевого интерфейса контейнеров Azure (CNI)

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

Prerequisites

• Ознакомьтесь с предварительными условиями для настройки базовой сети Azure CNI в AKS, так как к этой статье применяются те же предварительные требования.
• Просмотрите параметры развертывания для настройки базовой сети Azure CNI в AKS, так как применяются те же параметры.
• Механизм AKS и кластеры ручной сборки не поддерживаются.
• Версия Azure CLI 2.37.0 или более поздняя, aks-preview а также версия 2.0.0b2 расширения или более поздняя.
• Зарегистрируйте флаг функции на уровне подписки для вашей подписки: Microsoft.ContainerService/AzureVnetScalePreview.

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

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

Режим динамического выделения IP-адресов предлагает следующие преимущества:

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

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

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

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

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

Режим выделения статического блока

Выделение статических блоков помогает устранить потенциальные ограничения размера подсети pod и ограничения сопоставления адресов Azure, назначив блоки 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 работают с этим решением.

Limitations

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

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

max_pods = (N * 16) - 1 где N любое положительное целое число и N> 0

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

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

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

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

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

См. следующие примеры:

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