Compartilhar via

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

O NAP dá suporte às seguintes configurações de rede:

É recomendável usar o CNI do Azure com Cilium. O Cilium fornece recursos de rede avançados e é otimizado para desempenho com NAP.

Configurações de rede sem suporte para NAP

O NAP não dá suporte às seguintes configurações de rede:

  • Política de rede do Calico
  • Alocação de IP dinâmico

Configurações de sub-rede para NAP

O NAP implanta, configura e gerencia automaticamente o Karpenter em seus clusters do AKS e se baseia nos projetos de provedor Karpenter e AKS Karpenter de software livre. Você pode usar recursos AKSNodeClass para especificar configurações personalizadas de sub-rede para nós NAP em seus pools de nós, definindo o campo opcional vnetSubnetID, e o Karpenter usará a sub-rede que você especificar para o provisionamento de nós. Se você não especificar uma sub-rede, o Karpenter usará a sub-rede padrão configurada durante a instalação do Karpenter. Essa sub-rede padrão normalmente é a mesma sub-rede especificada durante a criação do cluster do AKS com o --vnet-subnet-id parâmetro no az aks create comando.

Essa abordagem permite que você tenha uma combinação de classes de nó, com algumas usando sub-redes personalizadas para cargas de trabalho específicas e outras usando 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.

A modificação vnetSubnetID de uma sub-rede válida para outra sub-rede válida não é uma operação com suporte. Se você alterar o vnetSubnetID para apontar para uma sub-rede válida diferente, o Karpenter detectará isso como desvio de sub-rede e impedirá o provisionamento de instâncias até que o problema seja resolvido revertendo o vnetSubnetID para a sub-rede original. Esse comportamento garante que os nós sejam provisionados apenas nas sub-redes pretendidas, mantendo a integridade e a segurança da rede. No entanto, há exceções a essa regra. Você só pode modificar o vnetSubnetID nos seguintes cenários:

  • Corrigindo uma ID de sub-rede malformada que impede o provisionamento de nós.
  • Corrigindo uma referência de sub-rede inválida que causa erros de configuração.
  • Atualizando um identificador de sub-rede que aponta para uma sub-rede inexistente ou inacessível.

Entender os intervalos CIDR (Roteamento entre Domínios Sem Classe) do cluster do AKS

Ao configurar a rede personalizada com vnetSubnetID, você é responsável por entender e gerenciar os intervalos CIDR do cluster para evitar conflitos de rede. Ao contrário dos pools de nós tradicionais do AKS criados por meio de modelos do 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 personalizadas

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:

# 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.

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.

Essa abordagem é a mais permissiva e concede permissões à identidade do cluster para ler e ingressar em qualquer sub-rede na VNet principal e fornece acesso de colaborador de rede.

Importante

Investigue a função "Colaborador de Rede" antes de aplicar essa abordagem ao cluster de produção.

Benefícios e considerações

A tabela a seguir descreve os benefícios e considerações da atribuição de permissões VNet amplas:

Benefícios Considerações
• Simplifica o gerenciamento de permissões.
• Elimina a necessidade de atualizar permissões ao adicionar novas sub-redes.
• Funciona bem para ambientes de locatário único.
• Funções quando uma assinatura atinge o número máximo de funções personalizadas.		 • Fornece permissões mais amplas do que estritamente necessário.
• Talvez não atenda aos requisitos de segurança estritos.

Permissões necessárias

Para atribuir permissões VNet amplas, conceda à identidade gerenciada do cluster as seguintes permissões na VNet:

# 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

Para obter um exemplo completo de configuração de rede personalizada e atribuição de amplas permissões de VNet, consulte a configuração da VNET personalizada – script de exemplo RBAC mais permissivo.

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.

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"

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/$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"

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

O Karpenter para Azure permite trazer suas próprias configurações de Interface de Rede de Contêiner (CNI BYO), seguindo a mesma política de suporte que o AKS. Isso significa que, ao usar uma CNI personalizada, a solução de problemas de suporte relacionada à rede está fora do escopo de quaisquer contratos ou garantias de nível de serviço.

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:

  • Last updated on