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

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

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

В этой статье показано, как использовать сеть kubenet для создания и использования подсети виртуальной сети для кластера AKS. Для получения дополнительной информации об опциях и соображениях сетей см. Основные понятия сети для Kubernetes и AKS.

Prerequisites

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

Перед тем как начать

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

Общие сведения о сети Kubenet с собственной подсетью

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

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

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

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

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

• В архитектуре kubenet требуется дополнительный шаг, что добавляет незначительные задержки в обмене данными между подами.
• Таблицы маршрутов и определяемые пользователем маршруты необходимы для использования kubenet, что повышает сложность операций.
  • Дополнительные сведения см. в статье Настройка исходящего трафика кластера с помощью пользовательской таблицы маршрутизации в AKS и настройка исходящего трафика кластера с исходящими типами в AKS.
• Прямая адресация для podов не поддерживается в Kubenet в результате его конструкции.
• В отличие от кластеров CNI Azure несколько кластеров kubenet не могут совместно использовать подсеть.
• AKS не применяет группы безопасности сети (NSG) к подсети и не изменяет группы безопасности сети, связанные с этой подсетью. Если вы предоставляете собственную подсеть и добавляете группы безопасности, связанные с этой подсетью, необходимо убедиться, что правила безопасности в группах безопасности позволяют трафик между узлом и ciDR pod. Дополнительные сведения см. в разделе "Группы безопасности сети".
• Функции , не поддерживаемые в kubenet , включают:
  • Сетевые политики Azure
  • пулы узлов Windows
  • Надстройка виртуальных узлов

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

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

В качестве компромисса, можно создать кластер AKS, использующий kubenet с подключением к существующей подсети виртуальной сети. Такой подход позволяет узлам получать определенные IP-адреса без необходимости заранее резервировать большое количество IP-адресов для потенциальных pod, которые могут запускаться в кластере. С помощью kubenet можно использовать гораздо меньший диапазон IP-адресов и поддерживать большие кластеры и требования приложений. Например, с диапазоном IP-адресов /27 в подсети можно запустить кластер узлов 20-25 с достаточной емкостью для масштабирования или обновления. Этот размер кластера может поддерживать до 2 200–2 750 pod (по умолчанию с максимальным количеством 110 pod на узел). Максимальное количество подов на узел, которое можно сконфигурировать с kubenet в AKS, равно 250.

Следующие основные вычисления сравнивают разницу в сетевых моделях:

• kubenet: простой диапазон IP-адресов /24 может поддерживать до 251 узлов в кластере. Каждая подсеть виртуальной сети Azure резервирует первые три IP-адреса для операций управления. Это число узлов может поддерживать до 27 610 модулей pod, при этом по умолчанию не более 110 модулей pod на узел.
• Azure CNI: тот же самый базовый /24 диапазон подсети может поддерживать максимум восемь узлов в кластере. Это число узлов может поддерживать только до 240 модулей pod, при этом по умолчанию не более 30 модулей pod на узел.

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

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

Выбор сетевой модели для использования

Следующие рекомендации помогут определить, когда каждая сетевая модель может быть наиболее подходящей:

Используйте kubenet, когда:

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

Используйте Azure CNI когда:

• У вас есть доступное адресное пространство IP.
• Большая часть взаимодействия pod происходит с ресурсами вне кластера.
• Вы не хотите управлять определяемыми пользователем маршрутами для подключения pod.
• Вам нужны расширенные функции AKS, такие как виртуальные узлы или Azure политики сети.

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

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

1. Создайте группу ресурсов с помощью команды az group create.

   az group create --name myResourceGroup --location eastus
   

2. Если у вас нет существующей виртуальной сети и подсети, создайте эти сетевые ресурсы с помощью 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 \
       --location eastus
   

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

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

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

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

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

  az aks create \
      --resource-group myResourceGroup \
      --name myAKSCluster \
      --network-plugin kubenet \
      --service-cidr 10.0.0.0/16 \
      --dns-service-ip 10.0.0.10 \
      --pod-cidr 10.244.0.0/16 \
      --vnet-subnet-id $SUBNET_ID \
      --generate-ssh-keys
  

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

  • --service-cidr является необязательным. Этот адрес используется для назначения IP-адресов внутренним службам в кластере AKS. Этот диапазон IP-адресов должен быть адресным пространством, которое не используется в других местах в вашей сетевой среде, включая любые локальные диапазоны сетей, если вы подключаете или планируете подключить ваши виртуальные сети Azure с помощью соединения Express Route или через VPN-подключение типа "сеть — сеть". Значение по умолчанию — 10.0.0.0/16.
  • --dns-service-ip является необязательным. Адрес должен быть .10-адресом диапазона IP-адресов вашей службы. Значение по умолчанию — 10.0.0.10.
  • --pod-cidr является необязательным. Этот адрес должен быть большим адресным пространством, которое не используется в других местах в сетевой среде. Этот диапазон включает любые локальные сетевые диапазоны, если вы подключаетесь или планируете подключиться к вашим виртуальным сетям Azure с помощью ExpressRoute или подключения Site-to-Site VPN. Значение по умолчанию — 10.244.0.0/16.
    • Этот диапазон адресов должен быть достаточно большим, чтобы вместить количество узлов, до которых требуется увеличить масштаб. Этот диапазон адресов нельзя изменить после развертывания кластера.
    • Диапазон IP-адресов pod используется для назначения адресного пространства /24 каждому узлу в кластере. В следующем примере --pod-cidr10.244.0.0/16 назначает первый узел 10.244.0.0/24, второй узел 10.244.1.0/24 и третий узел 10.244.24.0/24.
    • По мере масштабирования или обновления кластера платформа Azure продолжает назначать диапазон IP-адресов pod каждому новому узлу.

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

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

• Создайте управляемое удостоверение с помощью az identity команды. Если у вас есть управляемое удостоверение, найдите идентификатор субъекта с помощью az identity show --ids <identity-resource-id> команды.

  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"
  }
  

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

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

• Получите идентификатор ресурса виртуальной сети с помощью az network vnet show команды и сохраните его в виде переменной с именем VNET_ID.

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

• Назначьте управляемое удостоверение для разрешений участника сети кластера AKS в виртуальной сети с помощью az role assignment create команды и укажите <субъект-идентификатор>.

  az role assignment create --assignee <control-plane-identity-principal-id> --scope $VNET_ID --role "Network Contributor"
  
  # Example command
  az role assignment create --assignee 22222222-2222-2222-2222-222222222222 --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"
  

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

• Создайте кластер AKS с помощью az aks create команды и укажите идентификатор ресурса управляемого удостоверения уровня управления для аргумента, assign-identity чтобы назначить управляемое удостоверение, назначаемое пользователем.

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

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

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

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

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

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

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

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

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

1. Получите идентификатор подсети az network vnet subnet list с помощью команды.

   az network vnet subnet list --resource-group myResourceGroup --vnet-name myAKSVnet [--subscription]
   

2. Создайте кластер AKS с пользовательской подсетью, предварительно настроенной таблицей маршрутов, используя команду az aks create и предоставьте ваши значения для параметров --vnet-subnet-id и --assign-identity.

   az aks create \
       --resource-group myResourceGroup \
       --name myManagedCluster \
       --vnet-subnet-id mySubnetIDResourceID \
       --assign-identity controlPlaneIdentityResourceID \
       --generate-ssh-keys
   

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

В этой статье показано, как развернуть кластер AKS в существующей подсети виртуальной сети. Теперь вы можете приступить к созданию новых приложений с помощью Helm или развертывания существующих приложений с помощью Helm.