Использование сети kubenet с пользовательскими диапазонами IP-адресов в Службе Azure Kubernetes (AKS)

Статья
06/29/2022
Чтение занимает 12 мин

По умолчанию в кластерах AKS используется kubenet, а виртуальная сеть и подсеть Azure создаются автоматически. При использовании kubenet узлы получают IP-адрес из подсети виртуальной сети Azure. Модули pod получают IP-адреса из логически различающегося адресного пространства в подсеть виртуальной сети Azure узлов. Преобразование сетевых адресов (NAT) настраивается таким образом, чтобы модули pod могли получить доступ к ресурсам в виртуальной сети Azure. Исходный IP-адрес трафика преобразуется в первичный IP-адрес узла. Такой подход значительно уменьшает количество IP-адресов, которые необходимо зарезервировать в пространстве сети для объектов pod.

С помощью сетевого интерфейса контейнеров Azure (CNI) каждый объект pod получает IP-адрес из подсети, и к этому объекту pod можно получить прямой доступ. Эти IP-адреса должны быть уникальными во всей сети, и их следует планировать заранее. Для каждого узла предусмотрен параметр конфигурации, в котором указывается максимальное число объектов pod, которые он поддерживает. Затем на каждом узле заранее резервируется эквивалентное число IP-адресов для этого узла. Этот подход требует дополнительного планирования и часто приводит к исчерпанию IP-адресов или необходимости повторно создавать кластеры в подсети большего размера по мере увеличения потребностей вашего приложения. Вы можете настроить процесс так, чтобы при создании кластера или пулов узлов на узле развертывалось максимальное количество модулей pod. Если вы не укажете значение maxPods при создании пулов узлов, то будет применено значение по умолчанию для kubenet, равное 110.

В этой статье показано, как с помощью сети kubenet создать и использовать подсеть виртуальной сети для кластера AKS. Дополнительные сведения о сетях см. в статье Основные понятия сети в Службе Azure Kubernetes (AKS).

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

Виртуальная сеть для кластера AKS должна разрешать исходящее подключение к Интернету.
Не создавайте больше одного кластера AKS в одной подсети.
Кластеры AKS могут не использовать 169.254.0.0/16, 172.30.0.0/16, 172.31.0.0/16 или 192.0.2.0/24 в качестве диапазона адресов службы Kubernetes, диапазона адресов pod или диапазона адресов виртуальной сети кластера.
Удостоверение кластера, используемое кластером AKS, должно иметь по крайней мере разрешения роли Участник сетей в подсети виртуальной сети. Интерфейс командной строки помогает выполнять назначение ролей автоматически. Если вы используете шаблон ARM или другие клиенты, назначение ролей необходимо выполнять вручную. Кроме того, вам также понадобятся соответствующие разрешения, такие как разрешения роли "Владелец подписки", для создания удостоверения кластера и назначения ему разрешений. Если вы хотите определить пользовательскую роль вместо того, чтобы использовать встроенную роль участника сети, требуются следующие разрешения:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read

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

Чтобы использовать пулы узлов Windows Server, понадобится Azure CNI. Поскольку использование в качестве сетевой модели kubenet недоступно для контейнеров Windows Server.

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

Необходимо установить и настроить Azure CLI версии 2.0.65 или более поздней. Чтобы узнать версию, выполните команду az --version. Если вам необходимо выполнить установку или обновление, см. статью Установка Azure CLI 2.0.

Общие сведения о сети kubenet с использованием пользовательской подсети

Во многих средах виртуальные сети и подсети уже определены и для них выделены диапазоны IP-адресов. Эти ресурсы виртуальной сети используются для поддержки нескольких служб и приложений. Чтобы установить сетевое подключение, в кластерах AKS можно использовать kubenet (базовую сеть) или Azure CNI (расширенную сеть).

При использовании kubenet IP-адрес в подсети виртуальной сети получают только узлы. Объекты Pod не могут взаимодействовать напрямую. Для подключения между объектами pod в узлах применяются определяемая пользователем маршрутизация (UDR) и IP-пересылка. По умолчанию конфигурация перенаправления определяемых пользователем маршрутов и IP-адресов создается и обслуживается службой AKS, но вы можете создать собственную таблицу маршрутизации для настраиваемого управления маршрутами. Можно также развернуть объекты pod за службой, которая получает назначенный IP-адрес и распределяет нагрузку трафика для приложения. На приведенной ниже схеме показано, как узлы AKS (но не объекты pod) получают IP-адрес в подсети виртуальной сети:

Kubenet network model with an AKS cluster

Azure поддерживает не более 400 маршрутов в UDR, поэтому в кластере AKS не может быть больше 400 узлов. Виртуальные узлы AKS и политики сети Azure не поддерживаются в kubenet. Поэтому вы можете использовать поддерживаемые в kubenet политики сети Calico.

Благодаря Azure CNI каждый объект pod получает IP-адрес в IP-подсети и может напрямую взаимодействовать с другими объектами pod и службами. Размер кластеров может соответствовать размеру указанного диапазона IP-адресов. Тем не менее диапазон IP-адресов следует планировать заранее. Все эти IP-адреса используются узлами AKS в зависимости от максимального числа поддерживаемых объектов pod. Дополнительные сетевые компоненты и сценарии, такие как виртуальные узлы или политики сети (Azure или Calico), поддерживаются в Azure CNI.

Ограничения и рекомендации для kubenet

При проектировании kubenet требуется дополнительный прыжок, что значительно увеличивает задержку при обмене данными с pod.
Кроме того, для использования kubenet нужны таблицы маршрутизации и определяемые пользователем маршруты, что усложняет операции.
Прямая адресация pod не поддерживается для kubenet из-за свойств разработки kubenet.
В отличие от кластеров Azure CNI, несколько кластеров kubenet не могут совместно использовать подсеть.
AKS не применяет группы безопасности сети (NSG) к своей подсети и не будет изменять ни одну из групп безопасности сети, связанных с этой подсетью. Если вы предоставляете свою собственную подсеть и добавляете группы безопасности сети, связанные с этой подсетью, необходимо убедиться, что правила безопасности в группах безопасности сети разрешают трафик между узлом и CIDR pod. Дополнительные сведения см. в разделе Группы безопасности сети.
К возможностям, не поддерживаемым в kubenet, можно отнести:
- политики сети Azure, однако сетевые политики Calico kubenet поддерживает;
- пулы узлов Windows;
- надстройка виртуальных узлов.

Доступность и исчерпание IP-адресов

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

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

Благодаря kubenet можно использовать гораздо меньший диапазон IP-адресов и поддерживать большие кластеры и требования приложения. Например, даже в диапазоне IP-адресов /27 в вашей подсети можно запустить кластер с 20–25 узлами и иметь достаточно места для масштабирования или обновления. Этот размер кластера будет поддерживать до 2200–2750 объектов pod (по умолчанию максимум 110 объектов pod на каждом узле). Максимальное количество pod на узел, которое можно настроить с помощью kubenet в AKS составляет 110.

Приведенные ниже базовые расчеты показывают разницу между моделями сети.

kubenet. Простой диапазон IP-адресов /24 может поддерживать до 251 узла в кластере (каждая подсеть виртуальной сети Azure резервирует первые три IP-адреса для операций управления).
- Это число узлов может поддерживать до 27 610 объектов pod (по умолчанию максимум 110 объектов pod на каждом узле с kubenet).
Azure CNI. Такой же базовый диапазон подсети /24 поддерживает только до 8 узлов в кластере.
- Это число узлов может поддерживать только до 240 объектов pod (по умолчанию максимум 30 объектов pod на каждом узле с Azure CNI).

Примечание

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

Пиринг виртуальных сетей и подключения ExpressRoute

Для подключения к локальным ресурсам и в случае с kubenet, и в случае с Azure CNI можно использовать пиринг виртуальных сетей Azure или подключения ExpressRoute. Следует тщательно планировать диапазоны IP-адресов, чтобы избежать перекрытия и неправильной маршрутизации трафика. Например, во многих локальных сетях используется диапазон 10.0.0.0/8, который объявляется через подключение ExpressRoute. Рекомендуется создавать кластеры AKS в подсетях виртуальной сети Azure за пределами этого диапазона адресов, например 172.16.0.0/16.

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

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

Используйте kubenet в следующих случаях:

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

Используйте Azure CNI в следующих случаях:

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

Дополнительные сведения о том, какую сетевую модель лучше использовать, см. в разделе Сравнение сетевых моделей и их области поддержки.

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

Чтобы приступить к работе с kubenet и собственной подсетью виртуальной сети, сначала создайте группу ресурсов с помощью команды az group create. В следующем примере создается группа ресурсов с именем myResourceGroup в расположении eastus.

az group create --name myResourceGroup --location eastus

Если у вас нет существующей виртуальной сети и подсети, создайте эти сетевые ресурсы с помощью команды az network vnet create. В следующем примере создается виртуальная сеть с именем myAKSVnet и префиксом адреса 192.168.0.0/16. Также создается подсеть с именем myAKSSubnet и префиксом адреса 192.168.1.0/24.

az network vnet create \
    --resource-group myResourceGroup \
    --name myAKSVnet \
    --address-prefixes 192.168.0.0/16 \
    --subnet-name myAKSSubnet \
    --subnet-prefix 192.168.1.0/24

Получите идентификатор ресурса подсети и сохраните его в виде переменной:

SUBNET_ID=$(az network vnet subnet show --resource-group myResourceGroup --vnet-name myAKSVnet --name myAKSSubnet --query id -o tsv)

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

Теперь создайте кластер AKS в виртуальной сети и подсети с помощью команды az aks create.

Создание кластера AKS с управляемыми удостоверениями, назначаемыми системой

Кластер AKS можно создать с помощью управляемого удостоверения, назначаемого системой. Для этого выполните следующую команду CLI.

Примечание

При использовании удостоверения, назначаемого системой, azure-cli предоставит роль участника сети такому удостоверению после создания кластера. Управляемое удостоверение, назначаемое системой, поддерживается только для CLI. Если вы используете шаблон ARM или другие клиенты, необходимо использовать управляемое удостоверение, назначаемое пользователем.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID

Примечание

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

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet --network-policy calico \
    --vnet-subnet-id $SUBNET_ID

Создание кластера AKS с управляемыми удостоверениями, назначаемыми пользователем

Создание или получение управляемого удостоверения

Если у вас нет управляемого удостоверения, создайте его с помощью команды az identity.

az identity create --name myIdentity --resource-group myResourceGroup

Результат должен выглядеть так:

{                                  
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
  "location": "westus2",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Если у вас есть управляемое удостоверение, вы можете найти идентификатор участника, выполнив следующую команду:

az identity show --ids <identity-resource-id>

Результат должен выглядеть так:

{
  "clientId": "<client-id>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity",
  "location": "eastus",
  "name": "myIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Добавление назначения ролей для управляемого удостоверения

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

Чтобы назначить правильное делегирование в оставшихся действиях, получите необходимые идентификаторы ресурсов с помощью команд az network vnet show и az network vnet subnet show. Эти идентификаторы ресурсов хранятся как переменные и указываются в оставшихся действиях:

VNET_ID=$(az network vnet show --resource-group myResourceGroup --name myAKSVnet --query id -o tsv)

Теперь назначьте управляемое удостоверение для разрешений Участник сети кластера AKS в виртуальной сети с помощью команды az role assignment create. Укажите значение <principalId>, как показано в выходных данных предыдущей команды для создания удостоверения:

az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"

Пример

az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"

Примечание

Предоставление разрешений управляемому удостоверению кластера, используемому Azure, может занять до 60 минут.

Создание кластера AKS

Теперь вы можете создать кластер AKS с помощью управляемого удостоверения, назначаемого системой. Для этого выполните следующую команду CLI. Предоставьте идентификатор ресурса уровня управления через assign-identity.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --node-count 3 \
    --network-plugin kubenet \
    --vnet-subnet-id $SUBNET_ID \
    --enable-managed-identity \
    --assign-identity <identity-resource-id>

При создании кластера AKS автоматически создаются группа безопасности сети и таблица маршрутизации. Администрирование этих сетевых ресурсов выполняется на уровне управления AKS. Группа безопасности сети автоматически связывается с виртуальными сетевыми адаптерами на узлах. А таблица маршрутизации — с подсетью виртуальной сети. Правила групп безопасности сети и таблицы маршрутизации автоматически обновляются по мере создания и предоставления служб.

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

При использовании kubenet таблица маршрутизации должна существовать в подсетях кластера. AKS поддерживает использование существующих подсети и таблицы маршрутизации.

Если ваша пользовательская подсеть не содержит таблицу маршрутизации, AKS создает ее и будет добавлять в нее правила на протяжении всего жизненного цикла кластера. Если пользовательская подсеть содержит таблицу маршрутизации при создании кластера, AKS подтверждает существующую таблицу маршрутизации во время операций кластера и соответствующим образом добавляет или обновляет правила для операций поставщика облачных служб.

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

Настраиваемые правила можно добавить в пользовательскую таблицу маршрутизации и обновить. Однако поставщик облачных служб Kubernetes также добавляет правила, которые нельзя обновлять или удалять. Правила, такие как 0.0.0.0/0, должны всегда существовать в данной таблице маршрутизации и сопоставляться с целевым объектом шлюза Интернета, например NVA или другим шлюзом исходящего трафика. Будьте внимательны при обновлении правил, чтобы изменялись только настраиваемые правила.

Узнайте больше о настройке пользовательской таблицы маршрутизации.

Для работы в сети kubenet требуются упорядоченные правила таблицы маршрутизации, поскольку это залог успешной маршрутизации запросов. Из-за такой концепции таблицы маршрутизации следует постоянно обслуживать для каждого кластера, который на них полагается. Несколько кластеров не могут совместно использовать таблицу маршрутизации, поскольку это может привести к накладыванию маршрутизаций CIDR pod из разных кластеров и, как итог, к непредвиденной и нарушенной маршрутизации. При настройке нескольких кластеров в одной виртуальной сети или выделении виртуальной сети для каждого кластера необходимо учитывать следующие ограничения.

Ограничения

Перед созданием кластера AKS вам понадобится связать настраиваемую таблицу маршрутизации с подсетью.
Нельзя обновить связанный ресурс таблицы маршрутизации после создания кластера. Хотя ресурс таблицы маршрутизации нельзя обновить, можно изменить настраиваемые правила в таблице маршрутизации.
Каждый кластер AKS должен использовать одну уникальную таблицу маршрутизации для всех подсетей, связанных с кластером. Повторно использовать таблицу маршрутизации для нескольких кластеров нельзя, поскольку существует возможность перекрытия маршрутизаций CIDR pod и получения конфликтующих правил маршрутизации.
Для управляемого удостоверения, назначаемого системой, поддерживается только предоставление собственной подсети и таблицы маршрутов через Azure CLI. Это связано с тем, что CLI автоматически добавит назначение ролей. Если вы используете шаблон ARM или другие клиенты, вы должны использовать управляемое удостоверение, назначаемое пользователем, назначить разрешения перед созданием кластера и убедиться, что удостоверение, назначаемое пользователем, имеет разрешения на запись в вашу настраиваемую подсеть и настраиваемую таблицу маршрутов.
Использование одной таблицы маршрутизации с несколькими кластерами AKS не поддерживается.

Создав настраиваемую таблицу маршрутизации и связав ее с подсетью в виртуальной сети, можно приступить к созданию кластера AKS, использующего таблицу маршрутизации. В расположении, в котором вы планируете развернуть кластер AKS, нужно использовать идентификатор подсети. Эта подсеть также должна быть связана с пользовательской таблицей маршрутизации.

# Find your subnet ID
az network vnet subnet list --resource-group
                            --vnet-name
                            [--subscription]

# Create a kubernetes cluster with with a custom subnet preconfigured with a route table
az aks create -g MyResourceGroup -n MyManagedCluster --vnet-subnet-id <MySubnetID-resource-id>

Дальнейшие действия

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