Visão geral das configurações de rede para NAP (provisionamento automático de nós) no AKS (Serviço de Kubernetes do Azure)

Este artigo fornece uma visão geral dos requisitos e recomendações de configuração de rede para clusters do AKS (Serviço de Kubernetes do Azure) usando o NAP (provisionamento automático de nós). Ele aborda configurações com suporte, comportamento de sub-rede padrão, configuração de RBAC (controle de acesso baseado em função) e considerações de CIDR (roteamento entre domínios) sem classe.

Para obter uma visão geral do provisionamento automático de nós no AKS, consulte Visão geral do NAP (provisionamento automático de nós) no AKS (Serviço de Kubernetes do Azure).

Configurações de rede com suporte para NAP

Ao avaliar o suporte à rede para NAP, considere o modo IPAM (gerenciamento de endereço IP), o plug-in de rede, o plano de dados de rede e a política de rede. A tabela a seguir descreve as opções compatíveis com o NAP:

Use a Sobreposição de CNI do Azure com o plano de dados do Azure CNI Powered by Cilium. O Cilium fornece recursos de rede avançados e é otimizado para desempenho com NAP.

Configurações de sub-rede para NAP

Defina o campo opcional vnetSubnetID em um recurso AKSNodeClass para configurar a sub-rede personalizada que Karpenter usa para provisionar nós NAP. Se você não especificar vnetSubnetID, o Karpenter usará a sub-rede padrão configurada durante a instalação, que normalmente é a sub-rede especificada pelo --vnet-subnet-id parâmetro ao criar o cluster do AKS.

O NAP implanta, configura e gerencia automaticamente o Karpenter em seu cluster do AKS e se baseia nos projetos de provedor Karpenter e AKS Karpenter de software livre.

AKSNodeClass recursos no seu cluster do AKS podem especificar, cada um, um(a) vnetSubnetID diferente, o que permite configurações de sub-redes mistas entre pools de nós. Classes de nó que não especificam vnetSubnetID usam a configuração de sub-rede padrão do cluster.

Comportamento do desvio de sub-rede

O Karpenter monitora as alterações de configuração de sub-rede e detecta desvio quando o vnetSubnetID em um AKSNodeClass é modificado. Entender esse comportamento é fundamental ao gerenciar configurações de rede personalizadas.

Para clusters que usem uma rede virtual personalizada, alterar vnetSubnetID de uma sub-rede válida para outra faz com que os nós existentes associados ao AKSNodeClass fiquem em descompasso. Karpenter cria nós de substituição na nova sub-rede e interrompe normalmente os nós à deriva de acordo com os NodePool orçamentos de interrupção.

Antes de alterar vnetSubnetID, verifique se a identidade do cluster tem as permissões necessárias na nova sub-rede e se a sub-rede tem endereços IP disponíveis suficientes para nós de substituição. Os orçamentos de interrupção de pod e as anotações karpenter.sh/do-not-disrupt podem atrasar a substituição de descompasso voluntária de atraso.

Intervalos CIDR de cluster do AKS para NAP

Ao configurar a rede personalizada com vnetSubnetID, você precisa entender e gerenciar os intervalos CIDR do cluster para evitar conflitos de rede. Ao contrário dos pools de nós tradicionais do AKS que você cria por meio de modelos Azure Resource Manager (ARM), o Karpenter aplica CRDs (definições de recurso personalizadas) que provisionam nós instantaneamente sem a validação estendida fornecida pelo ARM.

Considerações de CIDR para configurações de sub-rede personalizada na NAP

Ao configurar vnetSubnetID, você deve:

• Verificar a compatibilidade com CIDR: verifique se as sub-redes personalizadas não entram em conflito com os intervalos CIDR existentes.
• Planejar a capacidade de IP: calcule os endereços IP necessários para o dimensionamento esperado.
• Validar conectividade: testar rotas de rede e regras de grupo de segurança.
• Monitorar o uso: acompanhe a utilização da sub-rede e planeje o crescimento.
• Configuração do documento: manter registros de decisões de design de rede.

Conflitos CIDR comuns

Esteja ciente dos seguintes cenários comuns de conflito CIDR ao usar sub-redes personalizadas com NAP:

Os exemplos a seguir mostram intervalos CIDR de sub-redes que entram em conflito com os CIDRs de pods e de serviços do cluster, bem como uma configuração que evita esses conflitos. Use esses padrões para validar os intervalos de sub-rede antes de configurar vnetSubnetID.

# 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

Configuração do RBAC para configurações de sub-rede personalizadas

Ao usar configurações de sub-rede personalizadas com NAP, você precisa garantir que o Karpenter tenha as permissões necessárias para ler informações de sub-rede e unir nós às sub-redes especificadas. Isso requer a configuração de permissões RBAC apropriadas para a identidade gerenciada do cluster.

A pessoa que executa os comandos a seguir deve ter permissão para criar a definição de função e as atribuições de função necessárias, como a função Administrador do Controle de Acesso Baseado em Funções. Não conceda permissões de gravação de atribuições de função à identidade do cluster, a menos que ela precise criar atribuições de função em outro cenário.

Obtenha o ID principal da identidade gerenciada do cluster. Use o comando que corresponde ao tipo de identidade do cluster:

CLUSTER_IDENTITY=$(az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query identity.principalId \
  --output tsv)

CLUSTER_IDENTITY=$(az identity show \
  --resource-group $IDENTITY_RESOURCE_GROUP \
  --name $IDENTITY_NAME \
  --query principalId \
  --output tsv)

Há duas abordagens principais para configurar essas permissões: atribuir permissões gerais de rede virtual (VNet) ou atribuir permissões específicas de sub-rede.

# 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-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Network Contributor" \
  --scope $VNET_ID

# 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-object-id $CLUSTER_IDENTITY \
  --assignee-principal-type ServicePrincipal \
  --role "Karpenter Subnet Access" \
  --scope $SUBNET_ID

Exemplo de configurações de sub-rede personalizadas

O exemplo a seguir mostra como configurar uma sub-rede personalizada para nós NAP usando o campo vnetSubnetID no recurso AKSNodeClass.

Defina o spec.vnetSubnetID campo como a ID de recurso de Azure completa da sub-rede de destino usando o formato/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/virtualNetworks/{vnetName}/subnets/{subnetName}.

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

O exemplo a seguir mostra como usar várias classes de nó com diferentes configurações de sub-rede:

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: frontend-nodes
spec:
  vnetSubnetID: "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/$VNET_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/$VNET_RESOURCE_GROUP/providers/Microsoft.Network/virtualNetworks/$VNET_NAME/subnets/$BACKEND_SUBNET_NAME"

Política de suporte de Traga sua própria CNI (CNI BYO)

O Karpenter para Azure permite trazer suas próprias configurações de CNI (Interface de Rede de Contêiner) e segue a mesma política de suporte que o AKS. O BYO CNI não torna compatível uma configuração que o NAP lista como sem suporte, como kubenet ou Calico. Quando você usa uma CNI personalizada, o suporte para solução de problemas relacionados à rede não está coberto por quaisquer acordos de nível de serviço ou garantias.

Detalhes do escopo de suporte

O seguinte descreve o que é e o que não é suportado ao usar o BYO CNI com o Karpenter.

• Com suporte: problemas de funcionalidade e integração específicos do Karpenter ao usar configurações de Trazer sua própria CNI (CNI BYO).
• Sem suporte: problemas de rede específicos da CNI, problemas de configuração ou solução de problemas ao usar plug-ins de CNI de terceiros.

Próximas etapas

Para obter mais informações sobre o provisionamento automático de nós no AKS, consulte os seguintes artigos:

• Usar provisionamento automático de nós em uma rede virtual personalizada
• Configurar pools de nós para provisionamento automático de nós no AKS
• Configurar políticas de interrupção para provisionamento automático de nós no AKS