Бөлісу құралы:

Подсеть pod pod для контейнеров Azure (CNI)

  • Мақала

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

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

Примечание.

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

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

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

  • Подсистема AKS и кластеры DIY не поддерживаются.

  • Версия Azure CLI 2.37.0 или более поздняя, aks-preview а также версия 2.0.0b2 расширения или более поздняя.

  • Зарегистрируйте флаг компонента уровня подписки для подписки: Microsoft.ContainerService/AzureVnetScalePreview.

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

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

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

Ограничения

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

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

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

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

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

Примечание.

Убедитесь, что виртуальная сеть имеет достаточно большое и непрерывное адресное пространство для поддержки масштабирования кластера.