Общие сведения о конфигурациях сети для автоматической подготовки узлов (NAP) в службе Azure Kubernetes (AKS)

В этой статье приведен обзор требований к конфигурации сети и рекомендаций для кластеров Службы Azure Kubernetes (AKS) с помощью автоматической подготовки узлов (NAP). В ней рассматриваются поддерживаемые конфигурации, поведение подсети по умолчанию, настройка управления доступом на основе ролей (RBAC) и безклассовая междоменная маршрутизация (CIDR).

Общие сведения об автоматической подготовке узлов в AKS см. в разделе "Обзор автоматической подготовки узлов" (NAP) в службе Azure Kubernetes (AKS).

Поддерживаемые конфигурации сети для NAP

NAP поддерживает следующие сетевые конфигурации:

• Оверлей Azure CNI
• Наложение Azure CNI с помощью Cilium
• Azure CNI

Рекомендуется использовать Azure CNI с Cilium. Cilium предоставляет расширенные сетевые возможности и оптимизирован для повышения производительности с помощью NAP.

Неподдерживаемые конфигурации сети для NAP

NAP не поддерживает следующие конфигурации сети:

• Политика сети Calico
• Динамическое выделение IP-адресов

Конфигурации подсети для NAP

NAP автоматически развертывает, настраивает и управляет Karpenter в кластерах AKS и основывается на проектах поставщика Karpenter и AKS Karpenter с открытым исходным кодом. Вы можете использовать ресурсы AKSNodeClass для указания собственных конфигураций подсетей для узлов NAP в ваших пулах узлов, используя необязательное поле vnetSubnetID, и Karpenter будет использовать указанную вами подсеть для развертывания узлов. Если вы не указываете подсеть, Karpenter использует подсеть по умолчанию, настроенную во время установки Karpenter. Эта подсеть по умолчанию обычно совпадает с подсетью, указанной во время создания кластера AKS с параметром --vnet-subnet-id в команде az aks create .

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

Поведение смещения подсети

Karpenter отслеживает изменения конфигурации подсети и обнаруживает отклонение, когда vnetSubnetID изменяется в AKSNodeClass. Понимание этого поведения важно при управлении пользовательскими конфигурациями сети.

Изменение vnetSubnetID одной допустимой подсети на другую допустимую подсеть не поддерживается. При изменении vnetSubnetID указателя на другую допустимую подсеть Карпентер обнаруживает это как смещение подсети и предотвращает подготовку узлов, пока проблема не будет устранена путем восстановления vnetSubnetID исходной подсети. Это гарантирует, что узлы развертываются только в предназначенных подсетях, поддерживая целостность сети и безопасность. Однако существуют исключения для этого правила. Можно изменить vnetSubnetID только в следующих сценариях:

• Исправление неправильно сформированного идентификатора подсети, который предотвращает подготовку узлов.
• Исправлена недопустимая ссылка на подсеть, которая приводит к ошибкам конфигурации.
• Обновление идентификатора подсети, указывающего на несуществующую или недоступную подсеть.

Понимание диапазонов маршрутизации CIDR (Classless Inter-Domain Routing) в кластере AKS

При настройке пользовательской сетевой конфигурации с vnetSubnetID вы отвечаете за понимание диапазонов CIDR кластера и управление ими, чтобы избежать сетевых конфликтов. В отличие от традиционных пулов узлов AKS, созданных с помощью шаблонов ARM, Karpenter применяет пользовательские определения ресурсов (CRD), которые мгновенно подготавливают узлы без расширенной проверки, которую предоставляет ARM.

Рекомендации по CIDR для пользовательских конфигураций подсети

При настройке vnetSubnetIDнеобходимо:

• Проверка совместимости CIDR. Убедитесь, что пользовательские подсети не конфликтуют с существующими диапазонами CIDR.
• Планирование емкости IP-адресов: Рассчитайте количество необходимых IP-адресов для ожидаемого масштабирования.
• Проверка подключения: проверка сетевых маршрутов и правил группы безопасности.
• Мониторинг использования: отслеживание использования подсети и планирование роста.
• Конфигурация документа: сохранение записей решений по проектированию сети.

Распространенные конфликты CIDR

Учтите следующие распространенные сценарии конфликтов CIDR при использовании пользовательских подсетей с NAP:

# Example conflict scenarios:
# Cluster Pod CIDR: 10.244.0.0/16  
# Custom Subnet:   10.244.1.0/24  ❌ CONFLICT

# Service CIDR:    10.0.0.0/16
# Custom Subnet:   10.0.10.0/24   ❌ CONFLICT

# Safe configuration:
# Cluster Pod CIDR: 10.244.0.0/16
# Service CIDR:     10.0.0.0/16  
# Custom Subnet:    10.1.0.0/24   ✅ NO CONFLICT

Настройка RBAC для пользовательских конфигураций подсети

При использовании пользовательских конфигураций подсети с NAP необходимо убедиться, что Karpenter имеет необходимые разрешения для чтения сведений о подсети и присоединения узлов к указанным подсетям. Для этого требуется настроить соответствующие разрешения RBAC для управляемого удостоверения кластера.

Существует два основных подхода к настройке этих разрешений: назначение разрешений широкой виртуальной сети или назначение разрешений подсети с областью действия.

Назначение разрешений широкой виртуальной сети

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

Это важно

Прежде чем применять этот подход к рабочему кластеру, изучите роль "Сетевой участник".

Преимущества и замечания

В следующей таблице описаны преимущества и рекомендации по назначению широких разрешений виртуальной сети:

Преимущества	Соображения
• Упрощает управление разрешениями. • Устраняет необходимость обновления разрешений при добавлении новых подсетей. • Хорошо подходит для сред с одним клиентом. • Функции, когда подписка достигает максимального числа пользовательских ролей.	• Предоставляет более широкие разрешения, чем необходимо. • Может не соответствовать строгим требованиям безопасности.

Необходимые разрешения

Чтобы назначить широкие разрешения виртуальной сети, предоставьте управляемому удостоверению кластера следующие разрешения в виртуальной сети:

# Get your cluster's managed identity
CLUSTER_IDENTITY=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query identity.principalId -o tsv)

# Get your VNet resource ID
VNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME"

# Assign Network Contributor role for subnet read/join operations
az role assignment create \
  --assignee $CLUSTER_IDENTITY \
  --role "Network Contributor" \
  --scope $VNET_ID

Полный пример настройки настраиваемой сети и назначения общих разрешений виртуальной сети см. в разделе "Настройка настраиваемой виртуальной сети" — наиболее распространенный пример скрипта RBAC.

Назначение разрешений с ограничением в подсети

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

Преимущества

Назначение разрешений подсети с заданной областью обеспечивает следующие преимущества:

• Следует принципу наименьшей привилегии.
• Предоставляет детализированный контроль доступа.
• Обеспечивает более высокую соответствие политикам безопасности.

Необходимые разрешения

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

# Get your cluster's managed identity
CLUSTER_IDENTITY=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query identity.principalId -o tsv)

# For each subnet, assign specific subnet permissions
SUBNET_ID="/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

# Create custom role definition for subnet access
cat > subnet-access-role.json << EOF
{
  "Name": "Karpenter Subnet Access",
  "IsCustom": true,
  "Description": "Allows reading subnet information and joining VMs to subnets",
  "Actions": [
    "Microsoft.Network/virtualNetworks/subnets/read",
    "Microsoft.Network/virtualNetworks/subnets/join/action"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/<subscription-id>"
  ]
}
EOF

# Create the custom role (only needed once per subscription)
az role definition create --role-definition subnet-access-role.json

# Assign the custom role to each subnet
az role assignment create \
  --assignee $CLUSTER_IDENTITY \
  --role "Karpenter Subnet Access" \
  --scope $SUBNET_ID

Для полного примера настройки пользовательской сети и назначения разрешений подсети с областью действия см. пример сценария с разрешениями подсети с областью действия.

Примеры пользовательских конфигураций подсети

В следующем примере показано, как настроить настраиваемую подсеть для узлов NAP с помощью vnetSubnetID поля в ресурсе AKSNodeClass :

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: custom-networking
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$SUBNET_NAME"

В следующем примере показано, как использовать несколько классов узлов с разными конфигурациями подсети:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$FRONTEND_SUBNET_NAME"
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: backend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

Использование собственной политики поддержки CNI (BYO CNI)

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

Сведения о области поддержки

Следующее описание показывает, что поддерживается и что не поддерживается при использовании BYO CNI с Karpenter:

• Поддержка: функциональные возможности и проблемы интеграции, специфичные для Karpenter, при использовании собственных (BYO) конфигураций CNI.
• Не поддерживается: проблемы с сетевым взаимодействием, проблемы конфигурации или их устранение при использовании сторонних подключаемых модулей CNI.

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

Дополнительные сведения об автоматической подготовке узлов в AKS см. в следующих статьях:

• Автоматическое предоставление узлов в вашей пользовательской виртуальной сети
• Настройка пулов узлов для автоматической подготовки узлов в AKS
• Настройка политик прерываний для автоматического предоставления узлов в AKS