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

Кластеры 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 значение по умолчанию 110 для kubenet.

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

Необходимые компоненты

• Виртуальная сеть для кластера AKS должна разрешать исходящее подключение к Интернету.
• Не создавайте больше одного кластера AKS в одной подсети.
• Кластеры AKS не могут использовать 169.254.0.0/16, 172.30.0.0/16172.31.0.0/16или 192.0.2.0/24 для диапазона адресов службы Kubernetes, диапазона адресов pod или диапазона адресов виртуальной сети кластера. Диапазон нельзя обновить после создания кластера.
• Удостоверение кластера, используемое кластером AKS, должно иметь по крайней мере роль участника сети в подсети в виртуальной сети. CLI помогает автоматически задать назначение ролей. Если вы используете шаблон 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 не могут взаимодействовать напрямую. Вместо этого определяемая пользователем маршрутизация (UDR) и IP-пересылка обрабатывают подключение между модулями pod между узлами. UDR и конфигурация IP-пересылки создаются и поддерживаются службой AKS по умолчанию, но вы можете использовать собственную таблицу маршрутов для пользовательского управления маршрутами, если вы хотите. Вы также можете развернуть модули pod за службой, которая получает назначенный IP-адрес и балансирует трафик для приложения. На приведенной ниже схеме показано, как узлы AKS (но не объекты pod) получают IP-адрес в подсети виртуальной сети:

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

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

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

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

Примечание.

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

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

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

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

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

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

Примечание.

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

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

Примечание.

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

• Создайте кластер 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 является необязательным. Этот адрес используется для назначения внутренних служб в кластере AKS IP-адрес. Этот диапазон IP-адресов должен быть диапазоном адресов, который не используется в сетевой среде, в том числе в локальной сети, при подключении или планировании подключения к виртуальным сетям Azure с помощью Express Route или VPN-подключения типа "сеть — сеть". Значение по умолчанию — 10.0.0.0/16.
  • --dns-service-ip является необязательным. Адрес должен быть .10-адресом диапазона IP-адресов службы. Значение по умолчанию — 10.0.0.10.
  • --pod-cidr является необязательным. Этот адрес должен быть большим адресным пространством, которое не используется в других местах в сетевой среде. Сюда входят все диапазоны в локальной сети, если вы подключаетесь или планируете подключаться к виртуальным сетям Azure с помощью Express Route или 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.2.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 или другие клиенты, необходимо использовать идентификатор субъекта управляемого удостоверения кластера для выполнения назначения ролей.

• Получите идентификатор ресурса виртуальной сети с помощью 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/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myAKSVnet" --role "Network Contributor"
  

Примечание.

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

Создание кластера 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 подтверждает существующую таблицу маршрутизации во время операций кластера и соответствующим образом добавляет или обновляет правила для операций поставщика облачных служб.

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

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

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

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

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

Примечание.

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

Управляемые удостоверения, назначаемые системой и назначаемые пользователем, поддерживаются при создании и использовании собственной виртуальной сети и таблицы маршрутов с подключаемым модулем сети Azure. Настоятельно рекомендуется использовать управляемое удостоверение, назначаемое пользователем, для сценариев BYO.

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